
XCMI General TC V5.601                                     04 April 2007


--  Module: General TC
--  File:   06gentc.txt, .dfm
--  Date:   04 April 2007 - Version 5.601.pub
--
--


                   Definitions of Textual Conventions
                 for General Configuration using SMIv2


Status of this Memo 

This document specifies the General Textual Conventions (TC).  All XCMI
conforming management agents, which implement the General MIB, SHALL
implement the General Base, Trap Client, and Trap View groups in the
XCMI General MIB.  

This document specifies an XCMI (Xerox Common Management Interface)
official standard MIB module for the entire Xerox community, and
requests discussion and suggestions for improvements.  Distribution of
this memo is unlimited (within Xerox).  

See section 9 'Supplement' of the XCMI General TC for implementation and
conformance guidance for this TC module.  

See section 3.1 'Overview of Groups in the General MIB' and section 3.3 
'Overview of Groups in IETF MIB-II' for diagrams of these two MIBs.  





















XCMI Working Group                 File 06gentc                 [Page 1]

XCMI General TC V5.601                                     04 April 2007



1.  Introduction

This document specifies the General Textual Conventions (TC).  All XCMI
conforming management agents, which implement the General MIB, SHALL
implement the General Base, Trap Client, and Trap View groups in the
XCMI General MIB.  

This General TC is a companion to the General MIB (published
separately).  

This General TC declares general textual conventions for the XCMI Suite,
for IMPORT into other XCMI MIB modules.  

This General TC has been written in ASN.1 (OSI Abstract Syntax Notation
One - CCITT X.208/209 | ISO 8824/8825), using the IETF SMIv2 (Structure
of Management Information - RFC 1442/1902/2578), the IETF TC for SMIv2
(Textual Conventions - RFC 1443/1903/2579), the IETF CONF for SMIv2
(Conformance Statements - RFC 1444/1904/2580), and the IETF Host
Resources MIB (RFC 2790) macros and textual conventions.  


































XCMI Working Group                 File 06gentc                 [Page 2]

XCMI General TC V5.601                                     04 April 2007



2.  SNMP Network Management Framework



2.1.  SNMPv1 Network Management Framework

The SNMPv1 Network Management Framework consists of the following:  

    o   RFC 1155 (STD 16) which defines Version 1 of the Structure of
        Management Information (SMIv1), the mechanisms used for
        describing and naming objects for the purpose of management; 
        
    o   RFC 1212 (STD 16) which defines a more concise description
        mechanism (Concise-SMIv1), which is wholly consistent with the
        SMIv1; 
        
    o   RFC 1157 (STD 15) which defines Version 1 of the Simple Network 
        Management Protocol (SNMPv1), the protocol used for network
        access to managed objects, including the security model SNMPv1c 
        (Community-based Security with SNMPv1 PDUs).  
        
    o   RFC 1215 which defines a convention for defining Traps for use
        with the SMIv1; 
        
    o   RFC 1213 (STD 17) which defines MIB-II, the core set of managed
        objects for the Internet suite of protocols, including the
        managed objects for SNMPv1 network management agents.  

The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.  


2.1.1.  Object Definitions

Managed objects are accessed via a virtual information store, termed the
Management Information Base or MIB.  Objects in the MIB are defined
using the subset of Abstract Syntax Notation One (ASN.1) defined in the
SMI.  In particular, each object object type is named by an OBJECT
IDENTIFIER, an administratively assigned name.  The object type together
with an object instance serves to uniquely identify a specific
instantiation of the object.  For human convenience, we often use a
textual string, termed the descriptor, to refer to the object type.  











XCMI Working Group                 File 06gentc                 [Page 3]

XCMI General TC V5.601                                     04 April 2007



2.2.  SNMPv2 Network Management Framework

The SNMPv2 Network Management Framework consists of the following:  

    o   RFC 1902 (Draft Standard) which defines Version 2 of the
        Structure of Management Information (SMIv2), the mechanisms used
        for describing and naming objects for the purpose of management 
        - note that RFC 1902 is now obsoleted by RFC 2578 (STD 58); 
        
    o   RFC 1903 (Draft Standard) which defines the SMIv2 Textual
        Conventions, the mechanisms used for defining 'named object
        types' (refinements of standard SMIv2 types), for use in
        defining managed objects - note that RFC 1903 is now obsoleted
        by RFC 2579 (STD 58); 
        
    o   RFC 1904 (Draft Standard) which defines the SMIv2 Conformance,
        the mechanisms used for defining 'conformance statements', for
        use in specifying precise levels of implementation conformance
        for management agents - note that RFC 1904 is now obsoleted by
        RFC 2580 (STD 58); 
        
    o   RFC 1905 (Draft Standard) which defines Version 2 of the Simple 
        Network Management Protocol (SNMPv2), the protocol used for
        network access to managed objects, without any security model
        (see RFC 1901 below) - note that RFC 1905 PDUs are also used by
        SNMPv3 in RFC 2574; 
        
    o   RFC 1906 (Draft Standard) which defines the SNMPv2 Transport
        Mappings, used by SNMPv2 'on-the-wire' over various protocol
        suites; 
        
    o   RFC 1907 (Draft Standard) which defines the SNMPv2 Agent MIB,
        the set of managed objects for SNMPv2 network management agents 
        - note that RFC 1907 is also now used with SNMPv1 (RFC 1157) and
        SNMPv3 (RFC 2574) agents.  

The SNMPv2 Network Management Framework is augmented by the following:  

    o   RFC 1901 (Experimental) which defines the security model SNMPv2c
        (Community-based Security with SNMPv2 PDUs).  













XCMI Working Group                 File 06gentc                 [Page 4]

XCMI General TC V5.601                                     04 April 2007



2.3.  SNMPv3 Network Management Framework

The SNMPv3 Network Management Framework consists of the following:  

    o   RFC 2578 (STD 58) which defines Version 2 of the Structure of
        Management Information (SMIv2), the mechanisms used for
        describing and naming objects for the purpose of management -
        note that RFC 1902 is now obsoleted by RFC 2578 (STD 58); 
        
    o   RFC 2579 (STD 58) which defines the SMIv2 Textual Conventions,
        the mechanisms used for defining 'named object types'
        (refinements of standard SMIv2 types), for use in defining
        managed objects - note that RFC 1903 is now obsoleted by RFC
        2579 (STD 58); 
        
    o   RFC 2580 (STD 58) which defines the SMIv2 Conformance, the
        mechanisms used for defining 'conformance statements', for use
        in specifying precise levels of implementation conformance for
        management agents - note that RFC 1904 is now obsoleted by RFC
        2580 (STD 58); 
        
    o   RFC 2571 (Draft Standard) which defines an architecture for
        describing SNMP Network Management Frameworks, including the
        SNMP Framework MIB; 
        
    o   RFC 2572 (Draft Standard) which defines message processing and
        dispatching for SNMP, including the SNMP Message Processing MIB;
        
    o   RFC 2573 (Draft Standard) which defines SNMP applications and
        dispatching for SNMP, including the SNMP Target and Notification
        MIBs (standardized trap subscription/registration) and SNMP
        Proxy MIB; 
        
    o   RFC 2574 (Draft Standard) which defines Version 3 of the Simple 
        Network Management Protocol (SNMPv3), the protocol used for
        network access to managed objects, including the security model
        SNMPv3u (User-based Security with SNMPv2 PDUs - see RFC 2575
        below) and the SNMP User-based Security MIB; 
        
    o   RFC 2575 (Draft Standard) which defines the View-based Access
        Control Model for use with all versions of SNMP, including the
        SNMP View-based Access Control MIB.  

The SNMPv3 Network Management Framework is augmented by the following:  

    o   RFC 1907 (Draft Standard) which defines the SNMPv2 Agent MIB,
        the set of managed objects for SNMPv2 network management agents 
        - note that RFC 1907 is also now used with SNMPv1 (RFC 1157) and
        SNMPv3 (RFC 2574) agents.  




XCMI Working Group                 File 06gentc                 [Page 5]

XCMI General TC V5.601                                     04 April 2007



3.  Managed Object Usage



3.1.  Overview of Groups in the General MIB

Sixteen object groups are specified in the General MIB.  Diagrams of
their relationships appear below and on the following pages:  brief
comment (eg, 'Housekeeping') above each box; object group name (eg,
'General Base') inside each box; conformance level in parentheses
('(Mandatory)' or '(Cond Mand)') inside each box.  An object group name 
in parentheses (eg, '(General Base)') is a reference to a previously
defined object group.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|    General    | INDEX {
|     Base      |   xcmGenBaseIndex }
|  (Mandatory)  |
|---------------|
        :
        :
        :        Supported Device Locales
        :           |---------------|
        :           |    General    | INDEX {
        :       1-n | Localization  |   hrDeviceIndex,
        :...........|  (Cond Mand)  |   xcmGenLocalizationIndex }
        :           |---------------|
        :
        :
        :         Dynamic Device Locales
        :           |---------------|
        :           |    Current    | INDEX {
        :       1-n | Localization  |   hrDeviceIndex }
        :...........|  (Cond Mand)  |
        :           |---------------|
        :
        :
        :         Static Device Locales
        :           |---------------|
        :           |     Fixed     | INDEX {
        :       1-n | Localization  |   hrDeviceIndex }
        :...........|  (Cond Mand)  |
                    |---------------|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

                Localization Groups in XCMI General MIB





XCMI Working Group                 File 06gentc                 [Page 6]

XCMI General TC V5.601                                     04 April 2007


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (General)   | INDEX {
|    (Base)     |   xcmGenBaseIndex }
|  (Mandatory)  |
|---------------|
        :
        :
        :       Supported Device Charsets
        :           |---------------|
        :           |     Coded     | INDEX {
        :       1-n | Character Set |   hrDeviceIndex,
        :...........|  (Cond Mand)  |   xcmGenCodedCharSetCharSet
        :           |---------------|
        :
        :
        :        Dynamic Charset Strings
        :           |---------------|
        :           |     Code      | INDEX {
        :       1-n |Indexed String |   hrDeviceIndex,
        :...........|  (Cond Mand)  |   xcmGenCodeIndexedStringIndex,
                    |---------------|   xcmGenCodeIndexedStringCharSet }
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

         Dynamic Charset Conversion Groups in XCMI General MIB




























XCMI Working Group                 File 06gentc                 [Page 7]

XCMI General TC V5.601                                     04 April 2007


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (General)   | INDEX {
|    (Base)     |   xcmGenBaseIndex }
|  (Mandatory)  |
|---------------|
        :
        :
        :       Advisory Contention Locks
        :           |---------------|
        :           |    General    | INDEX {
        :       1-n |     Lock      |   xcmGenLockIndex }
        :...........|  (Cond Mand)  |
        :           |---------------|
        :
        :
        :    Atomic Complex Reconfigurations
        :           |---------------|
        :           |    General    | INDEX {
        :       1-n |Reconfiguration|   hrDeviceIndex,
        :...........|  (Cond Mand)  |   xcmGenReconfIndex }
        :           |---------------|
        :
        :
        :    Atomic Complex Reconfigurations
        :           |---------------|
        :           |    General    | INDEX {
        :       1-n |    Option     |   hrDeviceIndex,
        :...........|  (Cond Mand)  |   xcmGenOptionIndex }
        :           |---------------|
        :
        :
        :      System/Device Installations
        :           |---------------|
        :           |    Client     | INDEX {
        :       1-n |     Data      |   xcmGenClientDataIndex }
        :...........|  (Cond Mand)  |
                    |---------------|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

     Contention Lock and Reconfiguration Groups in XCMI General MIB












XCMI Working Group                 File 06gentc                 [Page 8]

XCMI General TC V5.601                                     04 April 2007


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (General)   | INDEX {
|    (Base)     |   xcmGenBaseIndex }
|  (Mandatory)  |
|---------------|
        :
        :
        :       Trap Client Registrations
        :           |---------------|
        :           |     Trap      | INDEX {
        :       1-n |    Client     |   xcmGenTrapClientSNMPDomain,
        :...........|  (Mandatory)  |   xcmGenTrapClientSNMPAddress }
        :           |---------------|
        :                   :
        :                   :
        :        Trap View Registrations
        :           |---------------|
        :           |     Trap      | INDEX {
        :       1-n |     View      |   xcmGenTrapClientIndex,
        :...........|  (Mandatory)  |   xcmGenTrapViewObjectSubtree }
        :           |---------------|
        :
        :
        :       Notify Rule Registrations
        :           |---------------|
        :           |    Notify     | INDEX {
        :       1-n |     Rule      |   xcmGenNotifyRuleIndex }
        :...........|  (Cond Mand)  |
        :           |---------------|
        :                   :
        :                   :
        :      Notify Detail Registrations
        :           |---------------|
        :           |    Notify     | INDEX {
        :       1-n |    Detail     |   xcmGenNotifyRuleIndex,
        :...........|  (Cond Mand)  |   xcmGenNotifyDetailType,
                    |---------------|   xcmGenNotifyDetailIndex }
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

     Trap and Notification Registration Groups in XCMI General MIB












XCMI Working Group                 File 06gentc                 [Page 9]

XCMI General TC V5.601                                     04 April 2007


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (General)   | INDEX {
|    (Base)     |   xcmGenBaseIndex }
|  (Mandatory)  |
|---------------|
        :
        :
        :
        :
        :       Client-Side Localizations
        :           |---------------|
        :           |    Message    | INDEX {
        :       1-n |      Map      |   xcmGenMessageMapStringIndexOID }
        :...........|  (Cond Mand)  |
        :           |---------------|
        :
        :
        :       Server-Side Localizations
        :           |---------------|
        :           |    Message    | INDEX {
        :       1-n |     Text      |   xcmGenMessageTextStringIndexOID,
        :...........|  (Cond Mand)  |   xcmGenMessageTextTargetLocale }
                    |---------------|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

            Message Localization Groups in XCMI General MIB


























XCMI Working Group                File 06gentc                 [Page 10]

XCMI General TC V5.601                                     04 April 2007

Sixteen object groups are specified in the General MIB, as follows:  

1)  General Base Group (Mandatory) 
    - 'xcmGenBaseTable' contains one entry for general information on
    the common facilities on this host system (ie, localization,
    character sets, advisory locks, atomic complex reconfigurations,
    client data, SNMP versions, SNMP read/write/trap communities, SNMP
    traps, and 'labelled' server-side message strings); 
    
2)  Current Localization Group (Cond Mandatory) 
    - 'xcmGenCurrentLocalizationTable' contains one entry for each
    device's current (dynamic) localization on this host system; 
    
3)  General Localization Group (Cond Mandatory) 
    - 'xcmGenLocalizationTable' contains one entry for each device's
    supported localizations on this host system; 
    
4)  Fixed Localization Group (Cond Mandatory) 
    - 'xcmGenFixedLocalizationTable' contains one entry for each
    device's fixed (static) localization on this host system; 
    
5)  Code Indexed String Group (Cond Mandatory) 
    - 'xcmGenCodeIndexedStringTable' contains one entry for each
    device's current (dynamic) character set strings on this host
    system; 
    
6)  Coded Character Set Group (Cond Mandatory) 
    - 'xcmGenCodedCharSetTable' contains one entry for each device's
    supported character sets on this host system; 
    
7)  General Lock Group (Cond Mandatory) 
    - 'xcmGenLockTable' contains one entry for each advisory contention 
    lock (for client-side coordination) on this host system; 
    
8)  General Reconfiguration Group (Cond Mandatory) 
    - 'xcmGenReconfTable' contains one entry for each device's atomic
    complex reconfiguration set on this host system (usually used to
    reconfigure the XCMI Comms Config MIB); 
    
9)  General Option Group (Cond Mandatory) 
    - 'xcmGenOptionTable' contains one entry for each device's atomic
    complex reconfiguration options on this host system (usually used to
    reconfigure the XCMI Comms Config MIB); 
    
10) Client Data Group (Cond Mandatory) 
    - 'xcmGenClientDataTable' contains one entry for each client's
    cached system/device installation data on this host system (usually
    used to install network systems from an SA client tool); 
    
11) Trap Client Group (Mandatory) 
    - 'xcmGenTrapClientTable' contains one entry for each client's trap
    registration on this host system (includes the client address and
    version of SNMP for trap delivery); 


XCMI Working Group                File 06gentc                 [Page 11]

XCMI General TC V5.601                                     04 April 2007

    
12) Trap View Group (Mandatory) 
    - 'xcmGenTrapViewTable' contains one entry for each client's trap
    view registration on this host system (includes the client index and
    trap view subtree for trap delivery); 
    
13) Message Map Group (Cond Mandatory) 
    - 'xcmGenMessageMapTable' contains one entry for each static (agent
    generated) message string instance on this host system (supports
    client-side localization of message strings); 
    
14) Message Text Group (Cond Mandatory) 
    - 'xcmGenMessageTextTable' contains entries for each static (agent
    generated) message string instance on this host system for each of
    the supported locales on this host system (supports server-side
    localization of message strings); 
    
15) Notify Rule Group (Cond Mandatory) 
    - 'xcmGenNotifyRuleTable' contains one entry for each notify rule
    registration on this host system (includes the client URI, event
    names, and filters for notification); 
    
16) Notify Detail Group (Cond Mandatory) 
    - 'xcmGenNotifyDetailTable' contains one entry for each notify
    detail registration on this host system (additional client URI,
    event names, etc.  for event notification).  





























XCMI Working Group                File 06gentc                 [Page 12]

XCMI General TC V5.601                                     04 April 2007



3.2.  Relationship to other MIBs



3.2.1.  IETF MIB-II (RFC 1213)

The XCMI General MIB forms the common substrate for the XCMI Suite, in
the same fashion that the IETF MIB-II (RFC 1213) does for the IETF
public standard MIBs.  

Future:  It is intended that a future release of the XCMI General MIB
will provide 'group support' information about the IETF MIB-II in a
manner analogous to the XCMI Host Resources Ext MIB information about
the IETF Host Resources MIB (RFC 2790), in 'xcmHrGeneralGroupSupport',
by updates to the 'XcmGenGroupSupport' textual convention, and usage of 
the 'xcmGen[Group|GroupCreate|GroupUpdate]Support' objects in the
General Base group.  


3.2.2.  IETF Host Resources MIB (RFC 2790)

The General Localization, Current Localization, Fixed Localization, Code
Indexed String, Coded Character Set, General Reconfiguration, and
General Option groups of the General MIB are indexed by 'hrDeviceIndex'
from the 'hrDeviceTable' (Device Group) of the IETF Host Resources MIB
(RFC 2790), for fine-grained control of configuration.  

Best Current Practice:  The XCMI Editors now recommend that ALL devices 
in a managed system SHOULD be set to the same dynamic and static locales
(language, country, and code set).  Implementors SHOULD NOT permit the
locales of specific managed host system devices (except for the local
system console) to be set in an inconsistent fashion.  


3.2.3.  IETF Printer MIB (RFC 1759)

The General Localization and Current Localization groups of the General
MIB are generalizations of the Localization group and
'prtGeneralCurrentLocalization' object in the IETF Printer MIB (RFC
1759), which permits (most) XCMI MIB-defined strings to be supported in
a dynamic run-time locale (language, country, and code set).  

The Fixed Localization group of the General MIB is a related extension
which permits (most) XCMI MIB-defined strings to be supported in a
static install-time locale (language, country, and code set).  

The Code Indexed String and Coded Character Set groups of the General
MIB are related extensions which permit strings to be supported in a
fixed language but multiple character sets.  

Best Current Practice:  The XCMI Editors now recommend that ALL devices 
in a managed system SHOULD be set to the same dynamic and static locales

XCMI Working Group                File 06gentc                 [Page 13]

XCMI General TC V5.601                                     04 April 2007

(language, country, and code set).  Implementors SHOULD NOT permit the
locales of specific managed host system devices (except for the local
system console) to be set in an inconsistent fashion.  


3.2.4.  XCMI Standard MIBs

The XCMI General MIB forms the common substrate for the XCMI Suite, in
the same fashion that the IETF MIB-II (RFC 1213) does for the IETF
public standard MIBs.  













































XCMI Working Group                File 06gentc                 [Page 14]

XCMI General TC V5.601                                     04 April 2007



3.3.  Overview of Groups in IETF MIB-II

Ten object groups are specified in IETF MIB-II.  Diagrams of their
relationships appear below and on the following pages:  brief comment
(eg, 'Housekeeping') above each box; object group name (eg, 'System')
inside each box; IETF-specified conformance level in parentheses
('(Mandatory)' or '(Cond Mand)' or '(Deprecated)') inside each box;
XCMI-specified conformance level in square brackets ('[Required]' or
'[Recommended]' or '[Deprecated]') inside each box.  An object group
name in parentheses (eg, '(System)') is a reference to a previously
defined object group.  

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|    System     | Leaf Objects
|               | (No Tables)
|  (Mandatory)  |
|  [Required]   |
|---------------|
        :
        :
        :     Network and Direct Interfaces
        :           |---------------|
        :           |  Interfaces   | INDEX {
        :       1-n |               |   ifIndex }
        :...........|  (Mandatory)  |
        :           |  [Required]   |
        :           |---------------|
        :
        :
        :        Transmission Media OIDs
        :           |---------------|
        :           | Transmission  | Object Identifiers
        :       1-n |               | (No leaf/columnar objects)
        :...........|  (Mandatory)  |
        :           |  [Required]   |
        :           |---------------|
        :
        :
        :              SNMP Agent
        :           |---------------|
        :           |     SNMP      | Leaf Objects
        :       1-1 |               | (No Tables)
        :...........|  (Mandatory)  |
                    |  [Required]   |
                    |---------------|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

               XCMI Required Object Groups in IETF MIB-II



XCMI Working Group                File 06gentc                 [Page 15]

XCMI General TC V5.601                                     04 April 2007

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (System)    | Leaf Objects
|               | (No Tables)
|  (Mandatory)  |
|  [Required]   |
|---------------|
        :
        :
        :           Internet Protocol
        :           |---------------|
        :           |      IP       | Leaf Objects
        :       1-1 |               | (Tables Below)
        :...........|  (Cond Mand)  |
        :           | [Recommended] |
        :           |---------------|
        :                   :
        :       ............:
        :       :
        :       :        System IP Addresses
        :       :       |-------------------|
        :       :   1-n |       (IP)        | INDEX {
        :       :.......|    ipAddrTable    |   ipAdEntAddr }
        :       :       |-------------------|
        :       :
        :       :         System IP Routes
        :       :       |-------------------|
        :       :   1-n |       (IP)        | INDEX {
        :       :.......|   ipRouteTable    |   ipRouteDest }
        :       :       |-------------------|
        :       :
        :       :     System IP Address Mapping
        :       :       |-------------------|
        :       :   1-n |       (IP)        | INDEX {
        :       :.......| ipNetToMediaTable |   ipNetToMediaIfIndex,
        :               |-------------------|   ipNetToMediaIfAddress }
        :
        :
        :   Internet Control Message Protocol
        :           |---------------|
        :           |     ICMP      | Leaf Objects
        :       1-1 |               | (No Tables)
        :...........|  (Cond Mand)  |
                    | [Recommended] |
                    |---------------|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

             XCMI Recommended Object Groups in IETF MIB-II






XCMI Working Group                File 06gentc                 [Page 16]

XCMI General TC V5.601                                     04 April 2007

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (System)    | Leaf Objects
|               | (No Tables)
|  (Mandatory)  |
|  [Required]   |
|---------------|
        :
        :
        :     Transmission Control Protocol
        :           |---------------|
        :           |      TCP      | Leaf Objects
        :       1-1 |               | (Table Below)
        :...........|  (Cond Mand)  |
        :           | [Recommended] |
        :           |---------------|
        :                   :
        :       ............:
        :       :
        :       :      System TCP Connections
        :       :       |-------------------|
        :       :   1-n |       (TCP)       | INDEX {
        :       :.......|   tcpConnTable    |   tcpConnLocalAddress,
        :               |-------------------|   tcpConnLocalPort,
        :                                       tcpConnRemAddress,
        :                                       tcpConnRemPort }
        :
        :
        :        User Datagram Protocol
        :           |---------------|
        :           |      UDP      | Leaf Objects
        :       1-1 |               | (Table Below)
        :...........|  (Cond Mand)  |
                    | [Recommended] |
                    |---------------|
                            :
                ............:
                :
                :       System UDP Listeners
                :       |-------------------|
                :   1-n |       (UDP)       | INDEX {
                :.......|     udpTable      |   udpLocalAddress,
                        |-------------------|   udpLocalPort }
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

             XCMI Recommended Object Groups in IETF MIB-II








XCMI Working Group                File 06gentc                 [Page 17]

XCMI General TC V5.601                                     04 April 2007

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Housekeeping
|---------------|
|   (System)    | Leaf Objects
|               | (No Tables)
|  (Mandatory)  |
|  [Required]   |
|---------------|
        :
        :
        :
        :
        :      Network to Physical Address
        :           |---------------|
        :           |    Address    | INDEX {
        :       1-n |  Translation  |   atIfIndex,
        :...........| (Deprecated)  |   atNetAddress }
        :           | [Deprecated]  |
        :           |---------------|
        :
        :
        :       Exterior Gateway Protocol
        :           |---------------|
        :           |      EGP      | Leaf Objects
        :       1-1 |               | (Table Below)
        :...........| [Deprecated]  |
                    | [Deprecated]  |
                    |---------------|
                            :
                ............:
                :
                :       System EGP Neighbors
                :       |-------------------|
                :   1-n |       (EGP)       | INDEX {
                :.......|   egpNeighTable   |   egpNeighAddress }
                        |-------------------|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

              XCMI Deprecated Object Groups in IETF MIB-II
















XCMI Working Group                File 06gentc                 [Page 18]

XCMI General TC V5.601                                     04 April 2007



4.  Managed Object Definitions



4.1.  Definition of General Textual Conventions

-- .im 06gentc.mfm merging into this file

XEROX-GENERAL-TC DEFINITIONS ::= BEGIN
-- Module: General Textual Conventions
-- File:   06gentc.mib
-- Date:   04 April 2007 - Version 5.601.pub

IMPORTS
        MODULE-IDENTITY, OBJECT-IDENTITY,
        OBJECT-TYPE,
        Counter32, Gauge32, Integer32
                FROM SNMPv2-SMI       -- RFC 1442/1902/2578
        TEXTUAL-CONVENTION
                FROM SNMPv2-TC        -- RFC 1443/1903/2579
        xeroxCommonMIB
                FROM XEROX-COMMON-MIB;

xcmGeneralTC MODULE-IDENTITY
    LAST-UPDATED "0704040000Z" -- 04 April 2007
    ORGANIZATION "Xerox Corporation - XCMI Working Group"
    CONTACT-INFO "
                XCMI Editors
            E-Mail:     coherence@crt.xerox.com

    --
    --
            "
    DESCRIPTION "
        Version:    5.601.pub

        Xerox General Textual Conventions

        See section 9 'Supplement' of XCMI General TC for
        implementation and conformance guidance for this TC module.

        Copyright (C) 1995-2005 Xerox Corporation. All Rights Reserved."
    ::= { xeroxCommonMIB 50 }


XCMI Working Group                File 06gentc                 [Page 19]

XCMI General TC V5.601                                     04 April 2007


--
--  Xerox General Textual Conventions (in alphabetical order)
--

Cardinal16 ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The representation for non-negative integers.
        Used for indices in small tables where 0 means not specified.
        It avoids use of the sign bit."
    SYNTAX      INTEGER (0..32767)       -- biggest int = 2**15-1

Cardinal32 ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The representation for non-negative integers.
        Used for indices in large tables where 0 means not specified.
        Same size as ISO 10175 (avoids use of sign bit)."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Cardinal64High ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The high-order 31 bits of a 62-bit non-negative integer
        (0..2**62-1).  A manager must get or set the high
        and low parts in the same operation."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Cardinal64Low ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The low-order 31 bits of a 62-bit non-negative integer
        (0..2**62-1).  A manager must get or set the high
        and low parts in the same operation."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

CodedCountry ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        A two character country or territory abbreviation from
        ISO/IEC 3166:1993 - Codes for the Representation of
        Names of Countries.
        Examples: US, FR, DE
        A null string SHALL indicate that the country or territory
        is not defined."
    SYNTAX      OCTET STRING (SIZE(0..2))

CodedLanguage ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        A two character language abbreviation as defined in
        ISO/IEC 639:1988 - Codes For the Representation of
        Names of Languages.

XCMI Working Group                File 06gentc                 [Page 20]

XCMI General TC V5.601                                     04 April 2007

        Examples EN, GB, CA, FR, DE.
        An empty string SHALL indicate that the language
        is not defined."
    SYNTAX      OCTET STRING (SIZE(0..2))

CodeIndexedStringIndex ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The representation of string data which the agent can provide
        in one or more character sets (but not further localized).
        Typically this representation is used because the string data
        is relatively dynamic, changing too rapidly for full
        localization; or because the data exists inherently in only one
        or a limited number of character sets and cannot meaningfully
        be further localized.

        The value is an index into a single global string table, 
        xcmGenCodeIndexedStringTable.  A subsidiary index into the
        xcmGenCodeIndexedStringTable is the IANA registered enum
        (see the CodedCharSet textual-convention in RFC 1759) for the 
        coded character set desired by the management station (from 
        among the coded character sets supported by the SNMP agent).

        A 0 index value SHALL indicate that there is no associated entry
        in the string table.

        32 bits are needed because Jobs can use up 10-12 code-indexed
        strings per job."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Counter64High ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The high-order 32 bits of a 63-bit counter (0..2**63-1).
        A manager must get or set the high and low parts in the
        same operation."
    SYNTAX      Counter32  -- (0..2**32-1)

Counter64Low ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The low-order 31 bits of a 63-bit counter (0..2**63-1).
        A manager must get or set the high and low parts in the
        same operation."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Gauge64High ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The high-order 32 bits of a 63-bit gauge (0..2**63-1).
        A manager must get or set the high and low parts in the
        same operation."
    SYNTAX      Gauge32  -- (0..2**32-1)


XCMI Working Group                File 06gentc                 [Page 21]

XCMI General TC V5.601                                     04 April 2007


Gauge64Low ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The low-order 31 bits of a 63-bit gauge (0..2**63-1).
        A manager must get or set the high and low parts in the
        same operation."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Integer64High ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The high-order 32 bits of a 63-bit signed integer
        (-2**62..2**62-1).  A manager must get or set the high
        and low parts in the same operation."
    SYNTAX      Integer32

Integer64Low ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The low-order 31 bits of a 63-bit signed integer
        (-2**62..2**62-1).  A manager must get or set the high
        and low parts in the same operation."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Ordinal16 ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The representation for positive integers.
        Used for indices in small tables where 0 is illegal.
        It avoids use of the sign bit.."
    SYNTAX      INTEGER (1..32767)  -- biggest int = 2**15-1

Ordinal32 ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The representation for positive integers.
        Same size as ISO 10175 (avoids use of sign bit)."
    SYNTAX      INTEGER (1..2147483647)  -- biggest int = 2**31-1

Ordinal64High ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The high-order 31 bits of a 62-bit positive integer
        (1..2**62-1).  A manager must get or set the high
        and low parts in the same operation."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

Ordinal64Low ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The low-order 31 bits of a 62-bit positive integer
        (1..2**62-1).  A manager must get or set the high
        and low parts in the same operation."

XCMI Working Group                File 06gentc                 [Page 22]

XCMI General TC V5.601                                     04 April 2007

    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

--  Note:   Some SMIv1 compilers do NOT understand the 'ccitt' root
--          causing compile errors in XCMI modules converted to SMIv1.
--          'zeroDotZero' makes 'xcmGenZeroDotZero' a simple definition.
--
     zeroDotZero OBJECT IDENTIFIER ::= { ccitt 0 }
--

   xcmGenZeroDotZero OBJECT-IDENTITY
       STATUS      current  -- Actually deprecated
       DESCRIPTION "
           A value used for null object identifiers prior to XCMI v5.1.
           Do not use.  Instead use the standard definition in
           RFC 1902/2578 - 'zeroDotZero' - left here for compatibility."
       ::= { zeroDotZero 0 }

XcmFixedLocaleDisplayString ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This data type is used to model textual information in some
        localization (language, country, and character set), which is
        fixed (ie, NOT capable of being altered by management station
        request).  This textual information SHALL be represented in the
        localization which is indicated by the current value of
        'xcmGenFixedLocalizationIndex'."
    REFERENCE "
        See:    'XcmFixedLocaleUtf8String' in this module.
        See:    'XcmNamedLocaleUtf8String' in this module.
        See:    'InternationalDisplayString' in IETF Host Resources MIB
        (RFC 2790), 'DisplayString' in IETF SNMPv2 TC (RFC 1903/2579),
        'CodeIndexedStringIndex' in this module, and 'OCTET STRING' in
        OSI ASN.1 (CCITT X.208/X.209 | ISO 8824/8825)."
    SYNTAX      OCTET STRING (SIZE (0..255))

XcmFixedLocaleUtf8String ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This data type is used to model textual information in the UTF-8
        character set and some locale (language/country), which is
        fixed (ie, NOT capable of being altered by management station
        request).  This textual information SHALL be represented in
        UTF-8 and the locale which is indicated by the current value of
        'xcmGenFixedLocalizationIndex'."
    REFERENCE "
        See:    'UTF-8, a transformation of ISO 10646' (RFC 2279) and
        'IETF Policy on Character Sets and Languages' (RFC 2277).
        See:    'XcmFixedLocaleDisplayString' in this module.
        See:    'XcmNamedLocaleUtf8String' in this module.
        See:    'InternationalDisplayString' in IETF Host Resources MIB
        (RFC 2790), 'DisplayString' in IETF SNMPv2 TC (RFC 1903/2579),
        'CodeIndexedStringIndex' in this module, and 'OCTET STRING' in

XCMI Working Group                File 06gentc                 [Page 23]

XCMI General TC V5.601                                     04 April 2007

        OSI ASN.1 (CCITT X.208/X.209 | ISO 8824/8825)."
    SYNTAX      OCTET STRING (SIZE (0..255))

XcmNamedLocaleUtf8String ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This data type is used to model textual information in the UTF-8
        character set and some locale (language/country), which is
        named (ie, explicitly named by a parallel column or attribute or
        by the operation context)."
    REFERENCE "
        See:    'UTF-8, a transformation of ISO 10646' (RFC 2279) and
        'IETF Policy on Character Sets and Languages' (RFC 2277).
        See:    'XcmFixedLocaleDisplayString' in this module.
        See:    'XcmFixedLocaleUtf8String' in this module.
        See:    'InternationalDisplayString' in IETF Host Resources MIB
        (RFC 2790), 'DisplayString' in IETF SNMPv2 TC (RFC 1903/2579),
        'CodeIndexedStringIndex' in this module, and 'OCTET STRING' in
        OSI ASN.1 (CCITT X.208/X.209 | ISO 8824/8825)."
    SYNTAX      OCTET STRING (SIZE (0..255))

XcmGenGroupSupport ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The terse conformance statement of ALL mandatory, conditionally
        mandatory, and optional XCMI General MIB object groups which are
        supported by this management agent implementation (ie, version)
        on this host system, specified in a bit-mask.

        The current set of values (which MAY be extended in the future)
        is given below:

              1 : xcmGenCurrentLocalizationGroup    -- 2**0
              2 : xcmGenLocalizationGroup           -- 2**1
              4 : xcmGenCodeIndexedStringGroup      -- 2**2
              8 : xcmGenCodedCharSetGroup           -- 2**3
             16 : xcmGenFixedLocalizationGroup      -- 2**4
             32 : xcmGenLockGroup                   -- 2**5
             64 : xcmGenReconfGroup                 -- 2**6
            128 : xcmGenOptionGroup                 -- 2**7
            256 : xcmGenClientDataGroup             -- 2**8
            512 : xcmGenTrapClientGroup             -- 2**9
           1024 : xcmGenTrapViewGroup               -- 2**10
           2048 : xcmGenBaseGroup                   -- 2**11
           4096 : xcmGenMessageMapGroup             -- 2**12
           8192 : xcmGenMessageTextGroup            -- 2**13
          16384 : xcmGenNotifyRuleGroup             -- 2**14
          32768 : xcmGenNotifyDetailGroup           -- 2**15

        Usage:  Conforming management agents SHALL accurately
        report their support for XCMI General MIB object groups."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1



XCMI Working Group                File 06gentc                 [Page 24]

XCMI General TC V5.601                                     04 April 2007

XcmGenLogFullPolicy ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The current policy for handling job/request/event log 'full'
        (in MIBs, in shared RAM, on disk, etc), on this host system."
    SYNTAX      INTEGER {
        other(1),                       -- other
        unknown(2),                     -- unknown
        disableService(3),              -- disable service
        disableAndPauseService(4),      -- disable and pause service
        enableServiceAndFlushLog(5),    -- enable svc/flush entire log
        enableServiceAndFlushOldest(6)  -- enable svc/flush oldest entry
    }

XcmGenMessageMapStringLabel ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This syntax is used to specify a Xerox standard or experiemental
        message string label associated with the current value of the
        message string pointed to by 'xcmGenMessageMapStringIndexOID'.

        Usage:  Experimental message string labels SHOULD NOT be used in
        shipping versions of Xerox-branded products or services.  They
        exist solely to facilitate rapid product development cycles.

        Usage:  All Xerox message string label values SHALL
        be specified using display (NOT space) characters from the IANA
        registered charset 'utf-8' (ie, the UTF-8 octet-stream encoding
        of ISO-10646 UCS-4, described in RFC 2279).

        Usage:  All Xerox message string label values SHALL
        contain no more than 64 UTF-8 display characters AND no more
        than 128 total octets (in some scripts, less than 64 characters
        in UTF-8 octet-stream encoding).

        Usage:  All Xerox message string label values SHALL
        conform to the syntax specified below.  A 'format', 'namespace',
        'module', or 'field' component SHALL NOT contain hyphens.  A
        'format', 'namespace', or 'module' component SHALL use
        lowercase.  A 'field' or 'qualifier' component MAY use mixed
        case (see examples below).  A 'field' component MAY be use an
        abbreviated MIB object tag or other standardized identifier.
        ONLY a terminal 'qualifier' component MAY contain hyphens.  Each
        component SHALL be separated by a hyphen '-' character.

            --  Xerox message string label general ABNF syntax
            msg_label   =
                format '-' namespace '-' module '-' field '-' qualifier

            --  Xerox message string label alternatives ABNF syntax
            msg_label   =
                std_label / exp_label

        Usage:  All Xerox standard message string label values

XCMI Working Group                File 06gentc                 [Page 25]

XCMI General TC V5.601                                     04 April 2007

        SHALL conform to the refined syntax specified below.

            --  Xerox standard message label refined ABNF syntax
            std_label   =
                std_fmt '-' std_ns '-' module '-' field '-' qualifier

            --  Xerox standard format
            std_fmt     =
                'xs'        -- Xerox standard format
              / 'x?'        -- Xerox reserved formats (2 characters)

            --  Xerox standard namespace
            std_ns      =
                'ansi'      -- American National Standards Institute
              / 'dmtf'      -- Desktop Management Task Force
              / 'ecma'      -- European Computer Manufacturers Assn
              / 'ieee'      -- Institute Electrical/Electronic Engineers
              / 'ietf'      -- Internet Engineering Task Force
              / 'iso'       -- Int'l Organization for Standardization
              / 'itu'       -- Int'l Telecommunication Union (aka CCITT)
              / 'omg'       -- Object Management Group
              / 'pwg'       -- Printer Working Group
              / 'xcmi'      -- Xerox Common Management Interface
              / 'xopen'     -- X/Open (aka Open Group)
              / 'w3c'       -- World Wide Web Consortium

            --  Xerox message label common components
            module      =   -- module identifier w/out hyphens

            field       =   -- field identifier w/out hyphens

            qualifier   =   -- qualifer (MAY contain hyphens)

        Examples of well-formed standard message string labels:

            --  Examples of ISO standard media sizes
            xs-iso-10175-mediaSize-iso-a4   -- 210 mm by 297 mm
            xs-iso-10175-mediaSize-iso-b4   -- 250 mm by 353 mm

            --  Examples of ISO standard media types
            xs-iso-10175-mediaType-envelope
            xs-iso-10175-mediaType-transparency

            --  Examples of ISO standard media colors
            xs-iso-10175-mediaColor-white
            xs-iso-10175-mediaColor-yellow

            --  Examples of standard MIB objects
            xs-ietf-rfc1759-alertDescription-coverOpen
            xs-pwg-jobmon-processingMessage-completed
            xs-xcmi-11hostx-deviceDescription-dc230ST

        Usage:  All Xerox experimental message string label values
        SHALL conform to the refined syntax specified below.

XCMI Working Group                File 06gentc                 [Page 26]

XCMI General TC V5.601                                     04 April 2007


            --  Xerox experimental message label refined ABNF syntax
            exp_label   =
                exp_fmt '-' exp_ns '-' module '-' field '-' qualifier

            --  Xerox experimental format
            exp_fmt     =
                'xx'        -- Xerox experimental format

            --  Xerox experimental namespace
            exp_ns      =
                std_ns '.' prod_ns
            std_ns      =   -- as defined above for standard labels
            prod_ns     =   -- 'official' / 'working' product identifier

            --  Xerox message label common components
            module      =   -- as defined above for standard labels

            field       =   -- as defined above for standard labels

            qualifier   =   -- as defined above for standard labels

        Examples of well-formed experimental message string labels:

            xx-ietf.dcs265-rfc1759-alertDescription-skyIsFalling
            xx-xcmi.dc230-11hostx-deviceDescription-dc230ST
            xx-xcmi.belize-11hostx-systemFaultString-missingWidgets

        Note:   New or refined message label syntaxes MAY be defined in
        future versions of this XCMI General TC."
    REFERENCE "
        See:    'xcmGenMessageMapStringLabel' in XCMI General MIB.
        See:    'deviceLifetimeUsage', 'deviceAccountingUsage',
                'deviceLifetimeErrorCount', and
                'deviceLifetimeWarningCount' in 'XcmHrDevDetailType'
                textual convention in XCMI Host Resources Ext TC."
    SYNTAX      OCTET STRING (SIZE (0..128))

XcmGenNotifyDetailType ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The type of notify detail stored in this conceptual row
        in 'xcmGenNotifyDetailTable'.

        Usage:  Conforming XCMI management stations and agents SHALL
        encode notify details as UTF-8 strings (like SLPv2, RFC 2608).
        - Integers SHALL be encoded as (signed) decimal strings.
        - Booleans SHALL be encoded as 'true' or 'false' strings.
        - Strings SHALL be encoded as UTF-8 character strings.
        - Binary data (e.g., 'userCertificate') SHALL be stored
        in SLPv2 opaque encoding (leading '\FF' and escaped octets).

        Usage:  Conformant implementations MUST encrypt passwords, keys,
        and other security information in 'xcmGenNotifyDetailString'."

XCMI Working Group                File 06gentc                 [Page 27]

XCMI General TC V5.601                                     04 April 2007

    REFERENCE "
        See:    Section 5 'Subscription Object' and
                Section 5.3 'Subscription Template Attributes' and
                section 5.4 'Subscription Description Attributes' in
                IPP Notify (draft-ietf-ipp-not-spec-06.txt).
        See:    Section 5 'Service Attributes' (encoding rules) in
                Service Location Protocol v2 (RFC 2608)."
    SYNTAX      INTEGER {
--    * 'other'
--    * 'unknown'
--
--      -   Extensions of objects in 'xcmGenNotifyRuleTable'
--    * 'notifyRecipientURI'
--      - notify recipient URI (Uniform Resource Identifier)
--      - (MAY include parameters for SNMP and other URL schemes)
--      - (eg, 'snmp://machine.sample.com;version=2c;community=public'
--      - for SNMPv2c delivery with community-name of 'public')
--      - ('ftp:' and 'http:' URLs specify paths for event logs)
--      - see - Section 5.3.1 'notify-recipient-uri' in IPP Notify
--      - see - Generic URI Syntax (RFC 2396)
--      - see - The 'mailto:' URL Scheme (RFC 2368)
--      - (eg, 'mailto:joe@sample.com')
--      - see - Minimal PSTN address in Internet Mail (RFC 2303)
--      - (eg, 'mailto:VOICE=+3940226338@samplevoice.com')
--      - see - Minimal FAX address in Internet Mail (RFC 2304)
--      - (eg, 'mailto:FAX=+1.800.5553000/T33S=6377@sampleserv.com')
--
--    * 'notifyEventNames'
--      - notify event names - comma-delimited list of keywords
--      - (keywords of IPP 'notify-events' and SNMP traps and enums)
--      - (eg, 'lowPaper,jammed' from IETF HR MIB, RFC 2790)
--      - (MAY be scoped, eg, 'hrPrinterDetectedErrorState.jammed')
--      - (event enable/disable w/ 'active' and 'notInService')
--      - note - 'notifyEvent...' are parallel notify details
--      - see - Section 5.3.2 'notify-events' in IPP Notify
--      - see - TRAP-TYPE and NOTIFICATION-TYPE names in IETF/XCMI MIBs
--      - see - 'hrDeviceStatus' in IETF HR MIB (RFC 2790)
--      - see - 'xcmHrDevInfoXStatus' in XCMI HRX MIB
--      - see - 'hrPrinterDetectedErrorState' in IETF HR MIB (RFC 2790)
--      - see - 'prtAlertCode' in IETF Printer MIB (RFC 1759)
--
--    * 'notifyEventDelay'
--      - notify event delay - delay in seconds before event delivery
--      - (eg, '60' is 1 minute)
--      - note - 'notifyEvent...' are parallel notify details
--
--    * 'notifySeverityFilter'
--      - notify event severity filter
--      - (eg, '15' is report/warning/error)
--      - note - 'notifyEvent...' are parallel notify details
--      - see - 'XcmGenNotifySeverityFilter' in XCMI General TC
--
--    * 'notifyTrainingFilter'
--      - notify event training filter

XCMI Working Group                File 06gentc                 [Page 28]

XCMI General TC V5.601                                     04 April 2007

--      - (eg, '60' is none/trained/fieldService/management
--      - note - 'notifyEvent...' are parallel notify details
--      - see - 'XcmGenNotifyTrainingFilter' in XCMI General TC
--
--      -   No corresponding objects in 'xcmGenNotifyRuleTable'
--    * 'notifyMessageHeaderKeys'
--      - notify message header keys - comma-delimited list of headers
--      - (keywords of SMTP, HTTP, or other protocol headers)
--      - (eg, 'Reply-To')
--      - see - 'systemJobShowSenderContent[Key|OID]' in XCMI Svc Mon TC
--
--    * 'notifyMessageHeaderText'
--      - notify message header text - free-text header line(s)
--      - (eg, 'Content-Language: no-nyn, no-bok')
--      - see - 'systemJobShowSenderContentText' in XCMI Svc Mon TC
--
--    * 'notifyMessageContentKeys'
--      - notify message content keys - comma-delimited list of contents
--      - (keywords of SNMP objects or non-MIB message contents)
--      - (eg, 'sysName,sysLocation')
--      - see - Section 5.3.3 'notify-attributes' in IPP Notify
--      - see - 'systemJobShowSenderContent[Key|OID]' in XCMI Svc Mon TC
--
--    * 'notifyMessageContentText'
--      - notify message content text - free-text content line(s)
--      - (eg, 'Please call help desk')
--      - see - Section 5.3.4 'notify-user-data' in IPP Notify
--      - see - 'systemJobShowSenderContentText' in XCMI Svc Mon TC

        other(1),
        unknown(2),
        --  Extensions of objects in 'xcmGenNotifyRuleTable'
        notifyRecipientURI(10),
        notifyEventNames(20),
        notifyEventDelay(21),
        notifySeverityFilter(22),
        notifyTrainingFilter(23),
        --  No corresponding objects in 'xcmGenNotifyRuleTable'
        notifyMessageHeaderKeys(30),
        notifyMessageHeaderText(31),
        notifyMessageContentKeys(32),
        notifyMessageContentText(33)
    }

XcmGenNotifySchemeSupport ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The terse conformance statement of ALL notification URI schemes
        which are supported by this management agent implementation
        (ie, version) on this host system, specified in a bit-mask.

        The current set of values (which MAY be extended in the future)
        is given below:


XCMI Working Group                File 06gentc                 [Page 29]

XCMI General TC V5.601                                     04 April 2007


              1 : uriNotifySNMP   -- RFC 1215/1906  -  2**0 (SNMP)
              2 : uriNotifyMailto -- RFC 1738/2368  -  2**1 (SMTP)
              4 : uriNotifyHTTP   -- RFC 1738/2616  -  2**2 (HTTP)
              8 : uriNotifyHTTPS  -- RFC 1738/2396  -  2**3 (HTTPS)
             16 : uriNotifyFTP    -- RFC 1738/959   -  2**4 (FTP)

        Usage:  Conforming management agents SHALL accurately
        report their support for notification URI schemes."
    REFERENCE "
        See:    'xcmGenBaseNotifySchemeSupport' and
                'xcmGenBaseSNMPDomainSupport' in XCMI General MIB.
        See:    Cited IETF URI/URL specifications."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

XcmGenNotifySeverityFilter ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This type is used to specify a notification severity filter
        supported by this management agent for notification traffic
        in ALL domains specified by 'xcmGenBaseSNMPDomainSupport' and
        'xcmGenBaseNotifySchemeSupport' (for URI-based notification),
        specified in a bit-mask.

        The current set of values (which MAY be extended in the future)
        is given below:

              1 : severityReport            -- 2**0 (informational)
              2 : severityWarning           -- 2**1 (eg, low toner)
              4 : severitySoftError         -- 2**2 (non-critical)
              8 : severityHardError         -- 2**3 (critical)
             16 : severityTestReport        -- 2**4 (product-specific)
             32 : severityTestWarning       -- 2**5 (product-specific)
             64 : severityTestSoftError     -- 2**6 (product-specific)
            128 : severityTestHardError     -- 2**7 (product-specific)
            256 : severityInternalError     -- 2**8 (product-specific)

        Usage:  The terminology 'report', 'warning', and 'error' is
        coherent with the IETF IPP event notification work-in-progress
        and with the IETF Printer MIB (RFC 1759).

        Usage:  Individual trap definitions MAY further constrain which
        notifications are 'in scope'.

        Usage:  Conforming management agents SHALL accurately
        report their support for notification severity filters."
    REFERENCE "
        See:    'prtAlertSeverityLevel' in IETF Printer MIB (RFC 1759).
        See:    'xcmGenBaseNotifySeveritySupport' and
                'xcmGenTrapViewNotifySeverity' in XCMI General MIB."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1




XCMI Working Group                File 06gentc                 [Page 30]

XCMI General TC V5.601                                     04 April 2007

XcmGenNotifyTrainingFilter ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This type is used to specify a notification training filter
        supported by this management agent for notification traffic
        in ALL domains specified by 'xcmGenBaseSNMPDomainSupport' and
        'xcmGenBaseNotifySchemeSupport' (for URI-based notification),
        specified in a bit-mask.

        The current set of values (which MAY be extended in the future)
        is given below:

              1 : trainingOther             -- 2**0 (extension)
              2 : trainingUnknown           -- 2**1 (unknown)
              4 : trainingNone              -- 2**2 (untrained)
              8 : trainingTrained           -- 2**3 (trained)
             16 : trainingFieldService      -- 2**4 (field service)
             32 : trainingManagement        -- 2**5 (management)
             64 : trainingNoIntervention    -- 2**6 (management)

        Usage:  The terminology used here is coherent with the IETF
        Printer MIB (RFC 1759).

        Usage:  Individual trap definitions MAY further constrain which
        notifications are 'in scope'.

        Usage:  Conforming management agents SHALL accurately
        report their support for notification training filters."
    REFERENCE "
        See:    'prtAlertTrainingLevel' in IETF Printer MIB (RFC 1759).
        See:    'xcmGenBaseNotifyTrainingSupport' and
                'xcmGenTrapViewNotifyTraining' in XCMI General MIB."
    SYNTAX      INTEGER (0..2147483647)  -- biggest int = 2**31-1

XcmGenOptionValueSyntax ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        A reconfiguration option, device detail, storage detail,
        service detail, or security profile detail value syntax,
        used by system administrators and end users to specify
        the correct value syntax for this option or detail.

        Usage:  This option or detail value syntax is used to
        select which of the three value objects SHALL be used to
        contain the value of this option or detail.

      * An option or detail value syntax of 'oidObject'
        indicates that 'xcm...ValueOID' SHALL be used to specify
        an actual object type, defined with 'OBJECT-TYPE'.

      * An option or detail value syntax of 'oidAutonomous'
        indicates that 'xcm...ValueOID' SHALL be used to specify
        an autonomous object type, defined with 'OBJECT-IDENTITY' or
        simply 'OBJECT IDENTIFIER'.

XCMI Working Group                File 06gentc                 [Page 31]

XCMI General TC V5.601                                     04 April 2007


      * An option or detail value syntax of 'stringBinary'
        indicates that 'xcm...ValueString' SHALL be used to
        specify a (possibly) 'binary' (or 'non-printing') value string.

      * An option or detail value syntax of 'stringDisplay'
        indicates that 'xcm...ValueString' SHALL be used to
        specify a 'displayable' (or 'printing') value string.

      * An option or detail value syntax of 'stringLocalization'
        indicates that 'xcm...ValueLocalization' (for options) or
        'xcmGenFixedLocalizationIndex' (for details) SHALL be used
        to control the localization of the value string
        (with an underlying type of 'XcmGenFixedLocaleDisplayString').

      * An option or detail value syntax of 'stringCodedCharSet'
        indicates that 'xcm...ValueCodedCharSet' (for options) or
        'xcmGenFixedLocalizationIndex' (for details) SHALL be used
        to control the character set ONLY of the value string
        (with an underlying type of 'CodeIndexedStringIndex').

      * An option or detail value syntax of 'stringDynamicLocalization'
        indicates that 'xcmGenCurrentLocalization' SHALL be used
        to control the localization of the value string
        (with an underlying type of 'InternationalDisplayString').

      * An option or detail value syntax of 'stringUtf8Localization'
        indicates that 'xcm...ValueLocalization' (for options) or
        'xcmGenFixedLocalizationIndex' (for details) SHALL be used
        to control the localization of the value string
        (with an underlying type of 'XcmGenFixedLocaleUtf8String')."
    REFERENCE "
        See:    'xcmGenOptionTable' in XCMI General MIB
        See:    'xcmCommsOptionTable' in XCMI Comms Config MIB
        See:    'xcmHrDevDetailTable' in XCMI Host Resources Ext MIB
        See:    'xcmHrStorageDetailTable' in XCMI Host Resources Ext MIB
        See:    'xcmSvcMonServiceDetailTable' in XCMI Service Mon MIB
        See:    'xcmSecProfileDetailTable' in XCMI Security MIB"
    SYNTAX      INTEGER {
        --  'xcm...Value...' object holds value
        other(1),                       
        unknown(2),
        --  'xcm...ValueInteger' object holds value
        integerNumber(3),               -- (Integer32)
        integerCounter(4),              -- (Counter32)
        integerEnum(5),                 -- (INTEGER {..})
        integerGauge(6),                -- (Gauge32)
        integerIndex(7),                -- (Ordinal32|Cardinal32)
        integerTruthValue(8),           -- (TruthValue)
        --  'xcm...ValueOID' object holds value
        oidObject(9),                   -- (OBJECT-TYPE)
        oidAutonomous(10),              -- (OBJECT IDENTIFIER)
        --  'xcm...ValueString' object holds value
        stringBinary(11),               -- (OCTET STRING)

XCMI Working Group                File 06gentc                 [Page 32]

XCMI General TC V5.601                                     04 April 2007

        stringDisplay(12),              -- (DisplayString)
        stringLocalization(13),         -- (XcmFixedLocaleDisplayString)
        stringCodedCharSet(14),         -- (CodeIndexedStringIndex)
        stringDynamicLocalization(15),  -- (InternationalDisplayString)
        stringUtf8Localization(16)      -- (XcmFixedLocaleUtf8String)
    }

XcmGenReconfOptionState ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        The processing state of ALL pending reconfiguration options of
        this host system.

        A write to this object by an (authorized) management station
        invokes a request for validation (or activation) of ALL pending
        reconfiguration options of this host system.
        A read of this object returns 'idle', 'validateInProgress', or
        'activateInProgress' to report the processing state of the last
        'validate...' or 'activate...' request.
        It is mandatory that a conforming management agent ensure that,
        at system initialization, this object SHALL be set to a
        value of 'idle'.

      * 'idle' - NO processing is 'in progress' for either 'validate...'
        or 'activate...' of any pending reconfiguration options.
      * 'validateForImmediateChange' - this management agent (and host
        system) SHALL perform ALL possible and appropriate validation of
        ALL pending reconfiguration options (reporting the FIRST error
        encountered during validation), so that reconfiguration could
        be performed successfully via 'activateForImmediateChange'.
      * 'validateForRebootChange' - this management agent (and host
        system) SHALL perform ALL possible and appropriate validation of
        ALL pending reconfiguration options (reporting the FIRST error
        encountered during validation), so that reconfiguration could
        be performed successfully via 'activateForRebootChange'.
      * 'validateForImmediateReboot' - this management agent (and host
        system) SHALL perform ALL possible and appropriate validation of
        ALL pending reconfiguration options (reporting the FIRST error
        encountered during validation), so that reconfiguration could
        be performed successfully via 'activateForImmediateReboot'.
      * 'validateInProgress' - indicates that this management agent (and
        host system) are currently performing validation of ALL pending
        reconfiguration options.
        Note:   Conforming implementations NEED NOT support more than
        ONE of the above three 'validation...' operations.
      * 'activateForImmediateChange' - this management agent (and host
        system) SHALL perform immediate reconfiguration, NOT reboot, for
        ALL pending reconfiguration options (reporting the FIRST error
        encountered during validation).
        For all conforming implementations, this reconfiguration SHALL
        ALWAYS take effect immediately, WITHOUT host system reboot!
        Note:   Conforming implementations are STRONGLY encouraged to
        consider supporting 'benign' reconfiguration in this manner.
      * 'activateForRebootChange' - this management agent (and host

XCMI Working Group                File 06gentc                 [Page 33]

XCMI General TC V5.601                                     04 April 2007

        system) SHALL perform delayed reconfiguration, NOT reboot, for
        ALL pending reconfiguration options (reporting the FIRST error
        encountered during validation).
        For all conforming implementations, this reconfiguration SHALL
        ALWAYS take effect delayed, AFTER subsequent host system reboot!
        Note:   Conforming implementations NEED NOT support 'caching' of
        multiple outstanding 'sets of reconfiguration' in this manner.
      * 'activateForImmediateReboot' - this management agent (and host
        system) SHALL perform immediate reconfiguration, AND reboot, for
        ALL pending reconfiguration options (reporting the FIRST error
        encountered during validation).
        For all conforming implementations, this reconfiguration SHALL
        ALWAYS take effect immediately, WITH host system reboot!
        Note:   Conforming implementations are STRONGLY encouraged to
        consider secure alternatives (eg, Device Mgmt) for system reset.
      * 'activateInProgress' - indicates that this management agent (and
        host system) are currently performing activation of ALL pending
        reconfiguration options.
        Note:   Conforming implementations NEED NOT support more than
        ONE of the above three 'activation...' operations."
    REFERENCE "
        See:    'xcmGenReconfError[Index|Status]'"
    SYNTAX      INTEGER {
        idle(1),                        -- idle
        validateForImmediateChange(2),  -- validate for immediate change
        validateForRebootChange(3),     -- validate for reboot change
        validateForImmediateReboot(4),  -- validate for immediate reboot
        validateInProgress(5),          -- validate in progress
        activateForImmediateChange(6),  -- activate for immediate change
        activateForRebootChange(7),     -- activate for reboot change
        activateForImmediateReboot(8),  -- activate for immediate reboot
        activateInProgress(9)           -- activate in progress
    }

XcmGenRowPersistence ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This type is used to specify the persistence of this
        conceptual row in a table.

        Usage:  Conforming management agents SHALL interpret
        persistence as follows:

        1)  'volatile' rows NEED NOT be saved across power cycles,
            MAY contain one or more 'read-[create|write|only]' objects,
            and their underlying storage MAY be removable,
            and conforming management agents NEED NOT delete such rows
            (eg, a block in RAM, PCMCIA card, etc);
        2)  'nonvolatile' rows SHALL be saved across power cycles,
            MAY contain one or more 'read-[write|only]' objects,
            and their underlying storage MAY be removable,
            and conforming management agents MAY delete such rows
            (eg, a sector on CD-ROM, font cartridge, hard disk, etc);
        3)  'permanent' rows SHALL be saved across power cycles,

XCMI Working Group                File 06gentc                 [Page 34]

XCMI General TC V5.601                                     04 April 2007

            MAY contain one or more 'read-[write|only]' objects,
            and their underlying storage SHALL NOT be removable,
            and conforming management agents SHALL NOT delete such rows
            (eg, a sector on EEPROM, battery-backed RAM, bubble, etc);
        4)  'readonly' rows SHALL be saved across power cycles,
            SHALL contain exclusively 'read-only' objects,
            and their underlying storage SHALL NOT be removable,
            and conforming management agents SHALL NOT delete such rows
            (eg, a sector on ROM, ASIC, etc).

        Usage:  Dynamically created rows MAY ONLY be given 'volatile'
        or 'nonvolatile' persistence.

        Note:   Equivalent to SNMPv2 'StorageType' textual convention,
        which has an unfortunately ambiguous name."
    REFERENCE "
        See:    'hrStorageType' in the Storage group of the
                IETF Host Resources MIB (RFC 2790).
        See:    'StorageType' textual convention in the
                Historic SNMPv2 Party MIB (RFC 1447).
        See:    'StorageType' textual convention in the
                IETF SNMPv2 Textual Conventions (RFC 2579)."
    SYNTAX      INTEGER {
        other(1),
        unknown(2),
        volatile(3),                    -- lost across power cycles
        nonvolatile(4),                 -- saved across power cycles
        permanent(5),                   -- read-write, and no deletion
        readonly(6)                     -- read-only, and no deletion
    }

XcmGenSNMPDomain ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This type is used to specify a transport domain (address
        and name space) which is supported by this management agent
        for SNMP protocol traffic (SNMP responses, SNMP traps, etc),
        in ALL versions specified by 'xcmGenBaseSNMPVersionSupport'.

        This type is also used to allow the 'xcmGenTrapClientTable' to
        be used with any URI scheme (e.g., 'mailto:') for notifications,
        by specifying 'uriNotifyDomain'."
    REFERENCE "
        See:    'xcmGenBaseSNMPDomainSupport' and
                'xcmGenTrapClientSNMPDomain' in XCMI General MIB.
        See:    Cited IETF SNMP specifications."
    SYNTAX      INTEGER {
        snmpUDPDomain(1),               -- SNMP over UDP (Internet)
            --  'snmpUDPDomain' - SNMP Transport Mappings RFC 1449/1906
        snmpCLNSDomain(2),              -- SNMP over CLNS/TP4 (OSI)
            --  'snmpCLNSDomain' - SNMP Transport Mappings RFC 1449/1906
        snmpCONSDomain(3),              -- SNMP over CONS/TP0 (OSI)
            --  'snmpCONSDomain' - SNMP Transport Mappings RFC 1449/1906
        snmpDDPDomain(4),               -- SNMP over DDP (AppleTalk)

XCMI Working Group                File 06gentc                 [Page 35]

XCMI General TC V5.601                                     04 April 2007

            --  'snmpDDPDomain' - SNMP Transport Mappings RFC 1449/1906
        snmpIPXDomain(5),               -- SNMP over IPX (NetWare)
            --  'snmpDDPDomain' - SNMP Transport Mappings RFC 1449/1906
        snmpNetBIOSDomain(10),          -- SNMP over NetBIOS (session)
            --  'xcmSnmpNetbiosDomain' - XCMI Comms Config TC
        snmpNetBEUIDomain(11),          -- SNMP over NetBEUI (IBM DLC)
            --  'xcmSnmpNetbeuiDomain' - XCMI Comms Config TC
        snmpTCPDomain(20),              -- SNMP over TCP (Internet)
            --  'draft-irtf-nmrg-snmp-tcp-06.txt' (March 2001)
        snmpIPHostNameDomain(21),       -- SNMP over UDP using hostname
     -- instead of IP address
        uriNotifyDomain(30)             -- Any URI for notifications
    }

XcmGenSNMPVersion ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        This type is used to specify an SNMP version (RFC 1157, RFC
        1905, etc) which is supported by this management agent
        for SNMP protocol traffic (SNMP responses, SNMP traps, etc),
        in ALL domains specified by 'xcmGenBaseSNMPDomainSupport'."
    REFERENCE "
        See:    'xcmGenBaseSNMPVersionSupport' and
                'xcmGenTrapClientSNMPVersion' in XCMI General MIB.
        See:    Cited IETF SNMP specifications."
    SYNTAX      INTEGER {
        unknown(1),                     -- indeterminate
        other(2),                       -- some other version
        snmpV1Community(3),             -- SNMPv1 Community - RFC 1157
            --  SNMPv1 Standard w/ Communities (RFC 1157, May 1990)
        snmpV1Party(4),                 -- SNMPv1 Party - RFC 1352
            --  SNMPv1 Secure w/ Party MIB (RFC 1352, July 1992)
        snmpV2Party(5),                 -- SNMPv2 Party - RFC 1448
            --  SNMPv2 Historic w/ Party MIB (RFC 1448, April 1993)
        snmpV2Community(6),             -- SNMPv2 Community - RFC 1905
            --  SNMPv2 Std w/ Communities (RFC 1905, January 1996)
        snmpV2Usec(7),                  -- SNMPv2 Usec - RFC 1910
            --  SNMPv2 User-Based Security (RFC 1910, January 1996)
        snmpV2Star(8),                  -- SNMPv2 Star - no RFCs
            --  SNMPv2 User-Based Security (by Jeff Case, SNMP Research)
        snmpV2Secure(9),                -- SNMPv2 Secure - not published
            --  SNMPv2 Secure - never completed by SNMPv2 Working Group
        snmpV3Secure(10)                -- SNMPv3 Secure - RFC 2571-2575
            --  SNMPv3 Secure (RFC 2571-2575, April 1999)
    }

XcmGenSNMPv2ErrorStatus ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        Usage:  This type specifies the SMIv2 equivalent of the SMIv1
        'ErrorStatus' textual convention as an enumerated type.

        Note:   The enum of '0' (zero) in this textual convention is
        illegal in strict SMIv1 (see section 3.2.1.1 of RFC 1155), so

XCMI Working Group                File 06gentc                 [Page 36]

XCMI General TC V5.601                                     04 April 2007

        this TC must be converted to an integer range for pure SMIv1."
    REFERENCE "
        See:    'error-status' in SNMPv2 Protocol (RFC 1448/1905)"
    SYNTAX      INTEGER {
        noError(0),
        tooBig(1),
        noSuchName(2),                  -- for proxy compatibility
        badValue(3),                    -- for proxy compatibility
        readOnly(4),                    -- for proxy compatibility
        genErr(5),
        noAccess(6),
        wrongType(7),
        wrongLength(8),
        wrongEncoding(9),
        wrongValue(10),
        noCreation(11),
        inconsistentValue(12),
        resourceUnavailable(13),
        commitFailed(14),
        undoFailed(15),
        authorizationError(16),
        notWritable(17),
        inconsistentName(18), 
        failedDueToPowerSaverState(19), 
        requestTimedOut(20) 
    }

XcmGlobalUniqueID ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION "
        A management station or management agent specifies an object of
        type 'GlobalUniqueID' to uniquely label a client job request, a
        system administration request, or ANY other managed object (or
        set of managed objects) which are required to be unambiguously
        identified in a distributed network environment.

        An object of type 'GlobalUniqueID' SHALL be a textual string
        representation in standard 'dotted decimal' form of an OID.
        An object of type 'GlobalUniqueID' SHALL be composed of three
        mandatory sections (plus zero or more optional sections),
        as follows:

                nodeID.userID.seqID[[.subID1]...[.subIDn]]

        Each of the sections SHALL be separated by a dot ('.').  The
        three mandatory sections and any specified optional sections
        (in left to right order) SHALL be:

        1)  A globally unambiguous (within at least the network domain
            of the Requestor and Responder host systems) dotted decimal
            'nodeID' of the Requestor host system which explicitly or
            implicitly labelled this managed object, either:
            a)  A domain specific network layer address
                (eg, IETF IP address for 'nodeIDTypeIP'); OR

XCMI Working Group                File 06gentc                 [Page 37]

XCMI General TC V5.601                                     04 April 2007

            b)  A domain specific datalink MAC sublayer address
                (eg, ISO 8802-5 MAC address for 'nodeIDType88025').

        2)  A locally unambiguous (within at least the Requestor and/or
            Responder host systems) dotted decimal 'userID' (ie, user
            identifier) of the user who explicitly or implicitly
            labelled this managed object.

        3)  A locally unambiguous (within at least the Requestor and/or
            Responder host systems) dotted decimal 'seqID' (ie, sequence
            identifier) assigned by the host system or user who
            explicitly or implicitly labelled this managed object.

        4)  A locally unambiguous (within at least the Requestor and/or
            Responder host systems) dotted decimal 'subID' (ie, sequence
            sub-identifier) assigned by the host system or user who
            explicitly or implicitly labelled this managed object.

        Usage:  Conforming implementations MAY use one or more optional
        sections in an 'XcmGlobalUniqueID', for example to assign a
        sub-job identifier for job distribution services (e.g., fax to
        multiple destinations specified in the PDL of an input 'print'
        job - using an original 'xcmJobClientId' which is augmented by
        the server that splits up the destinations into separate jobs).

        Usage:  Conforming implementations SHALL NOT specify BOTH the
        first ('nodeID') and second ('userID') sections as 'empty', but
        one OR the other section MAY take on an 'empty' value (see
        below).  The third ('seqID') section SHALL NOT be 'empty'.

        Each of the three mandatory sections and any optional sections
        SHALL be composed of one mandatory and two optional subsections,
        as follows:

                sectionLength.sectionType.sectionValue

        Each of the subsections SHALL be separated by a dot ('.').  The
        three subsections (in left to right order) SHALL be:

        1)  A mandatory 'sectionLength', which specifies the decimal
            count of dotted decimal 'components' in the associated
            'sectionValue' - this 'sectionLength' SHALL NOT be
            self-inclusive and SHALL NOT include the single 'component'
            of the 'sectionType' - a 'sectionLength' of decimal zero
            ('0') SHALL indicate an 'empty' section, and the associated
            two subsections ('sectionType' and 'sectionValue') SHALL be
            omitted.

        2)  An optional 'sectionType', selected from the standard
            'sectionType' choices applicable to this section (below).

        3)  An optional 'sectionValue', specified as a dotted decimal
            string of 'components', each 'component' separated by a dot
            ('.').

XCMI Working Group                File 06gentc                 [Page 38]

XCMI General TC V5.601                                     04 April 2007


        The standard 'sectionType' choices (one set for each section)
        SHALL be as follows:

        1)  'nodeIDType' -- for mandatory 'nodeID' section
              1 : nodeIDTypeOther       -- Other
              2 : nodeIDTypeUnknown     -- Unknown
             11 : nodeIDTypeIP          -- Internet IP
             12 : nodeIDTypeCLNS        -- OSI CLNS
             13 : nodeIDTypeCONS        -- OSI CONS
             14 : nodeIDTypeDDP         -- AppleTalk DDP
             15 : nodeIDTypeIPX         -- NetWare IPX
             16 : nodeIDTypeNetBIOS     -- IBM NetBIOS
             31 : nodeIDType88023       -- ISO 8802-3 (Ethernet LAN)
             32 : nodeIDType88024       -- ISO 8802-4 (TokenBus LAN)
             33 : nodeIDType88025       -- ISO 8802-5 (TokenRing LAN)
             34 : nodeIDType88026       -- ISO 8802-6 (SlottedRing MAN)

        2)  'userIDType' -- for mandatory 'userID' section
              1 : userIDTypeOther       -- Other
              2 : userIDTypeUnknown     -- Unknown
             11 : userIDTypeSystem      -- System scope
             12 : userIDTypeSubnet      -- Subnet scope
             13 : userIDTypeNetwork     -- Network scope
             14 : userIDTypeGlobal      -- Global scope

        3)  'seqIDType' -- for mandatory 'seqID' section
              1 : seqIDTypeOther        -- Other
              2 : seqIDTypeUnknown      -- Unknown
             11 : seqIDTypeSystem       -- System generated
             12 : seqIDTypeProcess      -- Process generated
             13 : seqIDTypeThread       -- Thread generated

        4)  'subIDType' -- for optional 'subID' sections
              1 : subIDTypeOther        -- Other
              2 : subIDTypeUnknown      -- Unknown
             11 : subIDTypeSystem       -- System generated
             12 : subIDTypeProcess      -- Process generated
             13 : subIDTypeThread       -- Thread generated

        Usage:  A 'seqID' of any type SHALL be system-unique.

        Usage:  A 'seqID' of type 'seqIDTypeProcess' SHALL be prefixed
        (if necessary) by a system-unique dotted decimal 'processID'.

        Usage:  A 'seqID' of type 'seqIDTypeThread' SHALL be prefixed
        (if necessary) by a system-unique dotted decimal 'threadID'
        (possibly itself prefixed by a system-unique 'processID').

        Example:  A request submitted from a client end system running
        the IETF Internet Protocol Suite (IPS), with an IP address of
        '13.240.128.21', without a specified dotted decimal 'userID',
        might include an 'xcmJobClientId' of the following form:


XCMI Working Group                File 06gentc                 [Page 39]

XCMI General TC V5.601                                     04 April 2007


            '4.11.13.240.128.21.0.1.11.3045.1.11.23' [GlobalUniqueID]
            |---------1--------|2|----3----|---4---| [Sections]

        1)  The mandatory first section ('nodeID') consists of:
            a)  'sectionLength' of '4';
            b)  'sectionType' of '11' ('nodeIDTypeIP'); and
            c)  'sectionValue' of '13.240.128.21' (4 components).
        2)  The mandatory second section ('userID') consists of:
            a)  'sectionLength' of '0' (ie, 'empty' section).
        3)  The mandatory third section ('seqID') consists of:
            a)  'sectionLength' of '1';
            b)  'sectionType' of '11' ('seqIDTypeSystem'); and
            c)  'sectionValue' of '3045' (one component).
        4)  The optional fourth section ('subID') consists of:
            a)  'sectionLength' of '1';
            b)  'sectionType' of '11' ('subIDTypeSystem'); and
            c)  'sectionValue' of '23' (one component)."
    SYNTAX      OCTET STRING (SIZE (0..255))

--
--          The General TC Dummy Group (DO NOT USE)
--
--          DO NOT USE - Present to suppress compiler warnings ONLY!
--
--          Note:  The following objects have 'odd' use of case in their
--          names (ie, 'xCm...'), in order to make obvious their related
--          textual conventions

xCmGeneralDummy     OBJECT IDENTIFIER ::= { xcmGeneralTC 999 }

xCmGenCardinal16 OBJECT-TYPE
    SYNTAX      Cardinal16
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 1 }

xCmGenCardinal32 OBJECT-TYPE
    SYNTAX      Cardinal32
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 2 }

xCmGenCardinal64High OBJECT-TYPE
    SYNTAX      Cardinal64High
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 3 }

xCmGenCardinal64Low OBJECT-TYPE
    SYNTAX      Cardinal64Low

XCMI Working Group                File 06gentc                 [Page 40]

XCMI General TC V5.601                                     04 April 2007

    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 4 }

xCmGenCodedCountry OBJECT-TYPE
    SYNTAX      CodedCountry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 5 }

xCmGenCodedLanguage OBJECT-TYPE
    SYNTAX      CodedLanguage
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 6 }

xCmGenCodeIndexedStringIndex OBJECT-TYPE
    SYNTAX      CodeIndexedStringIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 7 }

xCmGenCounter64High OBJECT-TYPE
    SYNTAX      Counter64High
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 8 }

xCmGenCounter64Low OBJECT-TYPE
    SYNTAX      Counter64Low
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 9 }

xCmGenGauge64High OBJECT-TYPE
    SYNTAX      Gauge64High
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 10 }

xCmGenGauge64Low OBJECT-TYPE
    SYNTAX      Gauge64Low
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 11 }


XCMI Working Group                File 06gentc                 [Page 41]

XCMI General TC V5.601                                     04 April 2007


xCmGenInteger64High OBJECT-TYPE
    SYNTAX      Integer64High
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 12 }

xCmGenInteger64Low OBJECT-TYPE
    SYNTAX      Integer64Low
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 13 }

xCmGenOrdinal16 OBJECT-TYPE
    SYNTAX      Ordinal16
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 14 }

xCmGenOrdinal32 OBJECT-TYPE
    SYNTAX      Ordinal32
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 15 }

xCmGenOrdinal64High OBJECT-TYPE
    SYNTAX      Ordinal64High
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 16 }

xCmGenOrdinal64Low OBJECT-TYPE
    SYNTAX      Ordinal64Low
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 17 }

xCmGenFixedLocaleDisplayString OBJECT-TYPE
    SYNTAX      XcmFixedLocaleDisplayString
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 18 }

xCmGenGroupSupport OBJECT-TYPE
    SYNTAX      XcmGenGroupSupport
    MAX-ACCESS  not-accessible
    STATUS      current

XCMI Working Group                File 06gentc                 [Page 42]

XCMI General TC V5.601                                     04 April 2007

    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 19 }

xCmGenLogFullPolicy OBJECT-TYPE
    SYNTAX      XcmGenLogFullPolicy
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 20 }

xCmGenOptionValueSyntax OBJECT-TYPE
    SYNTAX      XcmGenOptionValueSyntax
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 21 }

xCmGenReconfOptionState OBJECT-TYPE
    SYNTAX      XcmGenReconfOptionState
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 22 }

xCmGenRowPersistence OBJECT-TYPE
    SYNTAX      XcmGenRowPersistence
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 23 }

xCmGenSNMPDomain OBJECT-TYPE
    SYNTAX      XcmGenSNMPDomain
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 24 }

xCmGenSNMPVersion OBJECT-TYPE
    SYNTAX      XcmGenSNMPVersion
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 25 }

xCmGenSNMPv2ErrorStatus OBJECT-TYPE
    SYNTAX      XcmGenSNMPv2ErrorStatus
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 26 }

xCmGenGlobalUniqueID OBJECT-TYPE
    SYNTAX      XcmGlobalUniqueID

XCMI Working Group                File 06gentc                 [Page 43]

XCMI General TC V5.601                                     04 April 2007

    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 27 }

xCmGenFixedLocaleUtf8String OBJECT-TYPE
    SYNTAX      XcmFixedLocaleUtf8String
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 28 }

xCmGenMessageMapStringLabel OBJECT-TYPE
    SYNTAX      XcmGenMessageMapStringLabel
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 29 }

xCmGenNamedLocaleUtf8String OBJECT-TYPE
    SYNTAX      XcmNamedLocaleUtf8String
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 30 }

xCmGenNotifySchemeSupport OBJECT-TYPE
    SYNTAX      XcmGenNotifySchemeSupport
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 31 }

xCmGenNotifySeverityFilter OBJECT-TYPE
    SYNTAX      XcmGenNotifySeverityFilter
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 32 }

xCmGenNotifyTrainingFilter OBJECT-TYPE
    SYNTAX      XcmGenNotifyTrainingFilter
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 33 }

xCmGenNotifyDetailType OBJECT-TYPE
    SYNTAX      XcmGenNotifyDetailType
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION "Dummy - DO NOT USE"
    ::= { xCmGeneralDummy 34 }


XCMI Working Group                File 06gentc                 [Page 44]

XCMI General TC V5.601                                     04 April 2007


END





















































XCMI Working Group                File 06gentc                 [Page 45]

XCMI General TC V5.601                                     04 April 2007



5.  Acknowledgements

--
--




































XCMI Working Group                File 06gentc                 [Page 46]

XCMI General TC V5.601                                     04 April 2007



6.  References



6.1.  General References

[1]   CCITT X.200:1992 | ISO 7498-1:1992 - OSI Basic Reference Model 
      
[2]   CCITT X.800:1992 | ISO 7498-2:1992 - OSI Security Reference Model 
      
[3]   CCITT X.650:1992 | ISO 7498-3:1992 - OSI Naming and Addressing
      Reference Model 
      
[4]   CCITT X.700:1992 | ISO 7498-4:1992 - OSI Management Reference
      Model 
      
[5]   CCITT X.208:1992 | ISO 8824:1992 - OSI Abstract Syntax Notation
      One (ASN.1) Specification 
      
[6]   CCITT X.209:1992 | ISO 8825:1992 - OSI Abstract Syntax Notation
      One (ASN.1) Basic Encoding Rules (BER) 
      
[7]   CCITT X.210:1993 | ISO ....:1993 - OSI Reference Model Conventions
      
[8]   CCITT X.710:1992 | ISO 9595:1992 - OSI Common Management
      Information Service (CMIS) 
      
[9]   CCITT X.711:1992 | ISO 9596:1992 - OSI Common Management
      Information Protocol (CMIP) 
      
[10]  IEEE 802.1B:1993 | ISO 15802-2:1995 - OSI LAN/MAN Management
      Protocol (LMMP) 
      
[11]  IETF RFC 1155 - Structure of Management Information Version 1
      (SMIv1 - May 1990) 
      
[12]  IETF RFC 1157 - Simple Network Management Protocol Version 1
      (SNMPv1 - May 1990) 
      
[13]  IETF RFC 1212 - Concise MIB Definitions for SNMPv1 (Concise SMIv1 
      - March 1991) 
      
[14]  IETF RFC 1213 - Management Information Base II (MIB-II in SMIv1 -
      March 1991) 
      
[15]  IETF RFC 1442/1902/2578 - Structure of Management Info Version 2
      (SMIv2 - April 1999) 
      
[16a]  IETF RFC 1441 to RFC 1452 - SNMP Version 2 (SNMPv2) Framework and
      Protocol Series (March 1993) - See detailed list below 
      


XCMI Working Group                File 06gentc                 [Page 47]

XCMI General TC V5.601                                     04 April 2007

[16b]  IETF RFC 1901 to RFC 1908 - SNMP Version 2 (SNMPv2) Framework and
      Protocol Series (January 1996) - See detailed list below 
      
[16c]  IETF RFC 2571 to RFC 2580 - SNMP Version 3 (SNMPv3) Framework and
      Protocol Series (April 1999) - See detailed list below 
      
[17]  IETF RFC 1418 - SNMP over OSI 
      
[18]  IETF RFC 1419 - SNMP over AppleTalk 
      
[19]  IETF RFC 1420 - SNMP over IPX 
      
[20]  IETF RFC 1514/2790 - Host Resources MIB (March 2000) 
      
[21]  IETF RFC 2233 - Interfaces Group MIB (November 1997) 
      
[22]  IETF RFC 1759 - Printer MIB (March 1995) 
      
[23]  IETF RFC 1780 - Internet Official Protocol Standards (March 1995) 


6.2.  IETF SNMPv2 Standards References

{1}   IETF RFC 1441/1901 - Introduction to SNMPv2 (INTRO for SNMPv2 -
      March 1993/January 1996) 
      
{2}   IETF RFC 1442/1902/2578 - Structure of Management Info Version 2
      (SMIv2 - March 1993/January 1996/April 1999) 
      
{3}   IETF RFC 1443/1903/2579 - Textual Conventions for SMIv2 (TC for
      SMIv2 - March 1993/January 1996/April 1999) 
      
{4}   IETF RFC 1444/1904/2580 - Conformance Statements for SMIv2 (CONF
      for SMIv2 - March 1993/January 1996/April 1999) 
      
{5}   IETF RFC 1445 - Administrative Model for SNMPv2 (ADMIN for SNMPv2
      - March 1993 - marked Historic in January 1996) 
      
{6}   IETF RFC 1446 - Security Protocols for SNMPv2 (SEC for SNMPv2 -
      March 1993 - marked Historic in January 1996) 
      
{7}   IETF RFC 1447 - Party MIB for SNMPv2 (PARTY for SNMPv2 - March
      1993 - marked Historic in January 1996) 
      
{8}   IETF RFC 1448/1905 - Protocol Operations for SNMPv2 (PROTO for
      SNMPv2 - March 1993/January 1996) 
      
{9}   IETF RFC 1449/1906 - Transport Mappings for SNMPv2 (TM for SNMPv2
      - March 1993/January 1996) 
      
{10}  IETF RFC 1450/1907 - Agent MIB for SNMPv2 (MIB for SNMPv2 - March
      1993/January 1996) 
      


XCMI Working Group                File 06gentc                 [Page 48]

XCMI General TC V5.601                                     04 April 2007

{11}  IETF RFC 1451 - Manager-to-Manager MIB for SNMPv2 (M2M for SNMPv2
      - March 1993 - marked Historic in January 1996) 
      
{12}  IETF RFC 1452/1908 - Coexistence between SNMPv1 and SNMPv2 (COEX
      for SNMPv2 - March 1993/January 1996) 


6.3.  IETF SNMPv3 Standards References

{1}   IETF RFC 2571 - Architecture for Describing SNMP Mgmt Frameworks
      (INTRO for SNMPv3 - January 1998) 
      
{2}   IETF RFC 2572 - Message Processing and Dispatching for SNMP (MP
      for SNMPv3 - January 1998) 
      
{3}   IETF RFC 2573 - Applications for SNMPv3 (APP for SNMPv3 - January
      1998) 
      
{4}   IETF RFC 2574 - User-based Security Model for SNMPv3 (USM for
      SNMPv3 - January 1998) 
      
{5}   IETF RFC 2575 - View-based Access Control Model for SNMPv3 (VACM
      for SNMPv3 - January 1998) 
      
{6}   IETF RFC 1442/1902/2578 - Structure of Management Info Version 2
      (SMIv2 - March 1993/January 1996/April 1999) 
      
{7}   IETF RFC 1443/1903/2579 - Textual Conventions for SMIv2 (TC for
      SMIv2 - March 1993/January 1996/April 1999) 
      
{8}   IETF RFC 1444/1904/2580 - Conformance Statements for SMIv2 (CONF
      for SMIv2 - March 1993/January 1996/April 1999) 























XCMI Working Group                File 06gentc                 [Page 49]

XCMI General TC V5.601                                     04 April 2007



7.  Security Considerations

Security considerations apply to all of the object groups in the XCMI
General MIB, particularly the groups supporting localization,
orchestrated reconfiguration, and trap registration.  

Security issues are addressed in the Device Mgmt group of the XCMI Host
Resources Extensions MIB (11hostx), in
'xcmHrDevMgmt[User|Operator|Admin]Password' objects.  

Security issues are addressed in the Config, Account, and User groups of
the XCMI Security MIB (63sec), in 'xcmSec[Account|User][Name|Index]',
'xcmSec[Account|User][Password|Passcode]' and
'xcmSec[Config|Account|User]MgmtData' objects.  


8.  Authors' Addresses


        XCMI Editors
Email:  coherence@crt.xerox.com
































XCMI Working Group                File 06gentc                 [Page 50]

XCMI General TC V5.601                                     04 April 2007



9.  Supplement



9.1.  XCMI Supplement to IETF MIB-II

The IETF and XCMI conformance requirements for all object groups defined
in IETF MIB-II (RFC 1213) are listed in the following table:  

Object Group                            IETF Conf       XCMI Conf
------------                            ---------       ---------
System                                  Mandatory       Required
Interfaces                              Mandatory       Required
Address Translation                     Deprecated      Deprecated
IP (Internet Protocol)                  Cond Mand       Recommended
ICMP (Internet Control Msg Protocol)    Cond Mand       Recommended
TCP (Transmission Control Protocol)     Cond Mand       Recommended
UDP (User Datagram Protocol)            Cond Mand       Recommended
EGP (Exterior Gateway Protocol)         Deprecated      Deprecated
Transmission (OIDs only, no objects)    Mandatory       Required
SNMP (agent instrumentation)            Mandatory       Required

Conformance:  XCMI conforming management agents SHALL implement the
System, Interfaces, Transmission, and SNMP object groups in IETF MIB-II,
to meet both XCMI and IETF Printer MIB minimum conformance requirements.

Conformance:  XCMI conforming management agents SHOULD implement the IP,
ICMP, TCP, and UDP object groups in IETF MIB-II, for competitive parity
with other network products and to improve interworking with third-party
network management stations and MIB module snap-in applications.  

Conformance:  XCMI conforming management agents SHOULD NOT implement the
Address Translation and EGP object groups in IETF MIB-II, as they are
Deprecated by both IETF and XCMI.  


9.1.1.  IETF MIB-II System (Mandatory)

This object group contains seven (7) leaf objects (with a fixed instance
qualifier of zero, by IETF SMI rules), zero (0) table objects, zero (0)
index objects, and zero (0) columnar objects.  

This object group is extended by the information provided by the System 
group of the IETF Host Resources MIB (RFC 2790).  

Conformance:  Implementation of the IETF MIB-II System group is
MANDATORY for conformance to the IETF MIB-II.  

Therefore, all XCMI conforming management agents SHALL implement the
IETF MIB-II System group.  

Usage:  For detailed implementation guidance on the System group, all

XCMI Working Group                File 06gentc                 [Page 51]

XCMI General TC V5.601                                     04 April 2007

XCMI conforming management stations and management agents SHOULD refer
to the SNMP Agent MIB (RFC 1907, January 1996).  

Note:  As of March 2001, RFC 1907 is being updated for SNMPv3 and IPv6
support.  

In the IETF MIB-II, system overview information is supported by the
following seven simple objects in the System group:  

1)  'sysDescr' (textual description of this host system);
2)  'sysObjectID' (product ID of this host system);
3)  'sysUpTime' (time since this host system was last initialized);
4)  'sysContact' (contact person for this host system);
5)  'sysName' (administratively-assigned name of this host system);
6)  'sysLocation' (physical location of this host system);
7)  'sysServices' (set of services offered by this host system).



Examples of System group objects:

sysDescr.0              = 'Xerox DocuCentre 230 ST v1.0;ESS 10.24,IOT 3.
    --  syntax 'DisplayString (SIZE (0..255))' (NVT ASCII string)
    --  defval omitted                  - system description
    --  (see - XCMI MIB Implementers Guide for detailed 
    --   usage/conformance requirements)

sysObjectID.0           = xcmPidDC230STV1
    --  syntax 'ProductID' (manufacturer defined object identifier)
    --  defval { zeroDotZero }    - no system product ID
    --  (see - section 'Usage of sysDescr and sysObjectID' in XCMI
    --  General TC for detailed usage/conformance requirements)
    --  product ID of this host system
    --  XCMI conforming management agents SHALL NOT set 'sysObjectID'
    --  to the product ID of an embedded NIC (network interface card),
    --  because remote software would then be prevented from displaying
    --  a correct graphic and textual description of the managed system.
    --  XCMI conforming management agents on network printers
    --  SHALL set 'hrDeviceID' for the printer device in IETF HR MIB
    --  to a value from the XCMI Product ID TC (93pidtc.mib) and SHALL
    --  set the SAME value in 'sysObjectID' in IETF MIB-II (RFC 1213),
    --  unless 'sysObjectID' represents an 'external print server'.
    --  (conformance - per IETF MIB-II, SHOULD include identification
    --  of ONLY network management subsystem software/hardware,
    --  but XCMI systems MUST ensure identity with 'hrDeviceID' for
    --  printer device in 'hrDeviceTable' of IETF HR MIB for coherence)
    --  (see - section 'Usage of hrDeviceTable' in XCMI HRX TC for
    --  related usage information on 'hrDeviceID')

sysUpTime.0             = 12437
    --  syntax 'TimeTicks' (hundredths of seconds since an epoch)
    --  defval { 0 }                    - initial system uptime
    --  time since this host system was last initialized
    --  compare w/ 'hrSystemUptime' in IETF HR MIB (host system uptime)

XCMI Working Group                File 06gentc                 [Page 52]

XCMI General TC V5.601                                     04 April 2007

    --  (conformance - per IETF MIB-II, SHOULD be time since last init
    --  of ONLY network management subsystem software/hardware,
    --  but XCMI systems MUST ensure identity with 'hrSystemUptime' of
    --  System group of IETF HR MIB for coherence)
    --  (note - spelling inconsistent with 'hrSystemUptime' in HR MIB)

sysContact.0            = 'John Doe, 716-444-9999'
    --  syntax 'DisplayString (SIZE (0..255))' (NVT ASCII string)
    --  defval { ''H }                  - no system contact person
    --  textual identification of contact person for this host system,
    --  including information on how to contact this person
    --  (conformance - per IETF MIB-II, no format required, but XCMI
    --  systems MUST ensure identity with 'prtGeneralCurrentOperator'
    --  in General group of IETF Printer MIB, RFC 1759, for coherence,
    --  so sets to 'sysContact' or 'prtGeneralCurrentOperator' SHALL
    --  set the other)

sysName.0               = 'blazer.acme.com'
    --  syntax 'DisplayString (SIZE (0..255))' (NVT ASCII string)
    --  defval { ''H }                  - no system name
    --  administratively-assigned name of this host system,
    --  by convention, this node's fully-qualified domain name (FQDN)
    --  (note - per IETF MIB-II, fully-qualified domain name, but XCMI
    --  systems SHOULD ensure identity with 'prtGeneralPrinterName'
    --  in General group of IETF Printer MIB v2, for coherence)

sysLocation.0           = 'east hallway, 3rd floor'
    --  syntax 'DisplayString (SIZE (0..255))' (NVT ASCII string)
    --  defval { ''H }                  - no system location
    --  physical location of this host system

sysServices.0           = 72
    --  syntax 'INTEGER (0..127)'
    --  defval { 72 }                   - system services (applications)
    --  set of services offered by this host system,
    --  per OSI Reference Model (ISO 7498) layers 1 to 7
    --  calculated as the sum of 2**(L - 1) for principal services
    --  (note - per IETF MIB-II, systems offering application services
    --  SHALL specify '72', ie, '2**(4-1) + 2**(7-1)')
    --  layer   functionality
    --  -----   -------------
    --  1       physical (eg, repeaters)
    --  2       datalink (eg, bridges)
    --  3       network (eg, routers)
    --  4       transport (eg, end-system hosts)
    --  5       session (eg, OSI session services)
    --  6       presentation (eg, OSI presentation services)
    --  7       application (eg, print services)


9.1.1.1.  Usage of sysDescr and sysObjectID

See XCMI MIB Implementer's Guide for information on sysDescr.  


XCMI Working Group                File 06gentc                 [Page 53]

XCMI General TC V5.601                                     04 April 2007


See:  'Usage of ifDescr and ifSpecific' in this XCMI General TC.  
See:  'Usage of hrDeviceType and hrDeviceDescr' in XCMI HRX TC.  


Conformance:  XCMI conforming managements agents SHALL NOT set
'sysObjectID' to the product ID of an embedded NIC (network interface
card), because remote software would then be prevented from displaying a
correct graphic and textual description of the managed system.  

Conformance:  XCMI conforming management agents SHALL set 'sysObjectID' 
in the System group of IETF MIB-II (RFC 1213) to the SAME value as
'hrDeviceID' in the Device group of IETF HR MIB (RFC 2790) for the
(first or only) printer device, for coherence; EXCEPT for an 'external
print server', when 'sysObjectID' SHALL identify the 'ProductID' of the 
'external print server' and 'hrDeviceID' SHALL identify the 'ProductID' 
of the connected printer (unless unavailable to the print server).  


9.1.2.  IETF MIB-II Interfaces (Mandatory)

This object group contains one (1) leaf object (with a fixed instance
qualifier of zero, by IETF SMI rules), one (1) table object, one (1)
index object, and twenty-one (21) columnar objects.  

This object group is extended by the information provided by the Device 
group of the IETF Host Resources MIB (RFC 2790).  

Conformance:  Implementation of the IETF MIB-II Interfaces group is
MANDATORY for conformance to the IETF MIB-II.  

Therefore, all XCMI conforming management agents SHALL implement the
IETF MIB-II Interfaces group.  

Usage:  For detailed implementation guidance on the Interfaces group,
all XCMI conforming management stations and management agents SHOULD
refer to the Interfaces Group MIB (RFC 2863, June 2000) and to the
Inverted Stack Table Extension to the Interfaces Group MIB (RFC 2864,
June 2000).  

Note:  As of March 2001, RFC 2863 and RFC 2864 are being updated for
IPv6 support.  


Examples of Interfaces group objects:

ifNumber.0              = 1
    --  syntax 'INTEGER' (count of network interfaces)
    --  defval { 0 }                    - no network interfaces
    --  number of network interfaces present on this host system,
    --  regardless of their current state

ifDescr.1               = 'IBM Token Ring Adapter Z1600 v1.2'
                        + ' - Network - 16 Mbps - AN299Z102'

XCMI Working Group                File 06gentc                 [Page 54]

XCMI General TC V5.601                                     04 April 2007

    --  syntax 'DisplayString (SIZE (0..255))' (NVT ASCII string)
    --  defval omitted                  - network interface description
    --  textual description of this network interface,
    --  including manufacturer and revision, and
    --  (optionally) serial number
    --  XCMI conforming management agents on network systems
    --  SHALL set 'hrDeviceDescr' for the network device in IETF HR MIB
    --  (RFC 2790) to a value appropriate for this interface and SHALL
    --  set the SAME value in 'ifDescr' in IETF MIB-II (RFC 1213),
    --  except that 'ifDescr' MAY contain additional information
    --  (conformance - per IETF MIB-II, SHOULD include manufacturer,
    --  product name, and version of hardware network interface,
    --  but XCMI systems MUST ensure identity with 'hrDeviceDescr' for
    --  network device in 'hrDeviceTable' of IETF HR MIB for coherence,
    --  so sets to 'ifDescr' or 'hrDeviceDescr' SHALL set the other)
    --  (see - section 'Usage of hrDeviceType and hrDeviceDescr' in XCMI
    --  HRX TC for detailed usage/conformance requirements)
    --  (note - per IETF HR MIB, each serial or parallel interface SHALL
    --  be listed ONLY in 'hrDeviceTable' of IETF HR MIB)
    --  (note - per IETF HR MIB, each network interface SHALL be listed
    --  in 'hrDeviceTable' and ALSO in 'hrNetworkTable' of IETF HR MIB)
    --  (see - section 'IETF HR Network Table (Cond Mandatory)' in XCMI
    --  HRX TC for detailed usage/conformance requirements)

ifType.1                = 'iso88025TokenRing(9)'
    --  syntax 'INTEGER' (enumeration of network interface types)
    --  defval { other }                - no network interface type
    --  type of this network interface
    --  (see - IANAifType-MIB for 'ifType' values - most current version
    --  available at 'ftp://ftp.isi.edu/mib/ianaiftype.mib')
    --  (see - Interfaces Group MIB in SMIv2, RFC 2233)

ifMtu.1                 = '4096'
    --  syntax 'INTEGER' (size in octets)
    --  defval omitted                  - network interface MTU size
    --  size of largest datagram which can be sent or received on
    --  this network interface, specified in octets
    --  MTU = maximum transmission unit
    --  (note - MTU size is interface and physical media dependent)
    --  (see - 'xcmCOOsilanEthernetMaxFrameSize' in XCMI CC TC)
    --  (see - 'xcmCOOsilanTokenRingMaxFrameSize' in XCMI CC TC)

ifSpeed.1               = 16777216
    --  syntax 'Gauge' (speed in bits/second)
    --  defval omitted                  - network interface speed
    --  speed of this network interface, specified in bits/second
    --  (note - speed is interface and physical media dependent)
    --  (see - 'xcmCOOsilanEthernetSpeed' in XCMI Comms Config TC)
    --  (see - 'xcmCOOsilanTokenRingSpeed' in XCMI Comms Config TC)

ifPhysAddress.1         = '08003702F60F'H
    --  syntax 'PhysAddress' (IEEE MAC address)
    --  (note - 'PhysAddress' defined as 'OCTET STRING' in IETF MIB-II)
    --  defval { 0 }                    - no network interface address

XCMI Working Group                File 06gentc                 [Page 55]

XCMI General TC V5.601                                     04 April 2007

    --  IEEE MAC address of this network interface,
    --  in packed binary form (eg, Token Ring MAC address is 6 octets)
    --  or zero length string if serial, parallel, etc.
    --  (note - format of physical address is interface dependent)
    --  (see - 'xcmCOOsilanEthernetMACAddress' in XCMI CC TC)
    --  (see - 'xcmCOOsilanTokenRingMACAddress' in XCMI CC TC)

ifAdminStatus.1         = 'up(1)'
    --  syntax 'INTEGER { up(1), down(2), testing(3) }'
    --  defval omitted                  - network interface admin status
    --  desired (requested) state of this network interface
    --  (note - testing(3) indicates no operational packets passed)
    --  (see - 'ifOperStatus' below)

ifOperStatus.1          = 'up(1)'
    --  syntax 'INTEGER { up(1), down(2), testing(3) }'
    --  defval omitted                  - network interface status
    --  current operational state of this network interface
    --  (note - testing(3) indicates no operational packets passed)
    --  (see - 'ifAdminStatus' above)

ifLastChange.1          = 10455
    --  syntax 'TimeTicks' (hundredths of seconds since an epoch)
    --  defval { 0 }                    - no network interface change
    --  last operational change of this network interface,
    --  specified as value of 'sysUpTime' when change occurred
    --  (see - 'ifOperStatus' above)
    --  (see - 'sysUpTime' in System group of IETF MIB-II)

ifInOctets.1            = 1264361
    --  syntax 'Counter'
    --  total octets received including framing chars

ifInUcastPkts.1         = 34246
    --  syntax 'Counter'
    --  total unicast packets received

ifInNUcastPkts.1        = 1247
    --  syntax 'Counter'
    --  total broadcast or multicast packets received

ifInDiscards.1          = 85
    --  syntax 'Counter'
    --  total valid packets received and discarded (eg, load-based)

ifInErrors.1            = 5148
    --  syntax 'Counter'
    --  total invalid packets received and discarded

ifInUnknownProtos.1     = 34
    --  syntax 'Counter'
    --  total unknown protocol packets received and discarded

ifOutOctets.1           = 1264361

XCMI Working Group                File 06gentc                 [Page 56]

XCMI General TC V5.601                                     04 April 2007

    --  syntax 'Counter'
    --  total octets sent including framing chars

ifOutUcastPkts.1        = 34246
    --  syntax 'Counter'
    --  total unicast packets sent including discards

ifOutNUcastPkts.1       = 1247
    --  syntax 'Counter'
    --  total broadcast or multicast packets sent including discards

ifOutDiscards.1         = 85
    --  syntax 'Counter'
    --  total valid packets discarded and not sent (eg, load-based)

ifOutErrors.1           = 5148
    --  syntax 'Counter'
    --  total invalid packets discarded and not sent

ifOutErrors.1           = 5148
    --  syntax 'Counter'
    --  total length (in packets) of output queue

ifSpecific.1            = zeroDotZero
    --  syntax 'OBJECT IDENTIFER'
    --  defval { zeroDotZero }    - no media-specific MIB
    --  media-specific MIB for this network interface
    --  XCMI conforming management agents SHALL set 'ifSpecific' to the
    --  appropriate media-specific MIB (eg, RFC 1643, Ethernet MIB),
    --  if they implement such a MIB


9.1.2.1.  Usage of ifDescr and ifSpecific

Conformance:  XCMI conforming management agents SHALL set 'ifDescr' in
the Interfaces group of IETF MIB-II (RFC 1213) to the SAME value as
'hrDeviceDescr' in the Device group of IETF HR MIB (RFC 2790) for the
corresponding network device, for coherence.  

Conformance:  XCMI conforming management agents SHALL ensure that a set 
to 'ifDescr' sets the corresponding 'hrDeviceDescr' object and vice
versa, for coherence.  

See:  'Usage of sysDescr and sysObjectID' in this XCMI General TC.  
See:  'Usage of hrDeviceType and hrDeviceDescr' in XCMI HRX TC.  


Example of 'ifDescr' with all required, recommended, and optional
components:

ifDescr.0 =
    'IBM Token Ring Adapter Z1600 v1.2 - Network - 16 Mbps - AN299Z102'
    |      |                |     |      |         |         |
    vendor product          model rev    type      speed     serial no

XCMI Working Group                File 06gentc                 [Page 57]

XCMI General TC V5.601                                     04 April 2007


Conformance:  XCMI conforming management agents SHALL set 'ifSpecific'
in the Interfaces group of IETF MIB-II (RFC 1213) to the value of the
appropriate media-specific MIB (eg, RFC 1643, Ethernet MIB), if they
implement such a MIB.  


9.1.3.  IETF MIB-II Address Translation (Deprecated)

This object group contains zero (0) leaf objects (with a fixed instance
qualifier of zero, by IETF SMI rules), one (1) table object, one (1)
index object, and two (2) columnar objects.  

Conformance:  XCMI conforming management agents SHOULD NOT implement the
Address Translation group, per RFC 1213.  


9.1.4.  IETF MIB-II IP (Cond Mandatory)

This object group contains twenty (20) leaf objects (with a fixed
instance qualifier of zero, by IETF SMI rules), three (3) table objects,
four (4) index objects, and seventeen (17) columnar objects.  

Conformance:  XCMI conforming management agents SHOULD implement the IP
group for competitive equivalence.  

Usage:  For detailed implementation guidance on the IP group, all XCMI
conforming management stations and management agents SHOULD refer to RFC
2011 (November 1996).  

Note:  As of March 2001, RFC 2011 is being updated for IPv6 support.  


9.1.5.  IETF MIB-II ICMP (Cond Mandatory)

This object group contains twenty-six (26) leaf objects (with a fixed
instance qualifier of zero, by IETF SMI rules), zero (0) table objects, 
zero (0) index objects, and zero (0) columnar objects.  

Conformance:  XCMI conforming management agents SHOULD implement the
ICMP group for competitive equivalence.  

Usage:  For detailed implementation guidance on the ICMP group, all XCMI
conforming management stations and management agents SHOULD refer to RFC
2011 (November 1996).  

Note:  As of March 2001, RFC 2011 is being updated for IPv6 support.  


9.1.6.  IETF MIB-II TCP (Cond Mandatory)

This object group contains fourteen (14) leaf objects (with a fixed
instance qualifier of zero, by IETF SMI rules), one (1) table object,
four (4) index objects, and one (1) columnar object.  

XCMI Working Group                File 06gentc                 [Page 58]

XCMI General TC V5.601                                     04 April 2007


Conformance:  XCMI conforming management agents SHOULD implement the TCP
group for competitive equivalence.  

Usage:  For detailed implementation guidance on the TCP group, all XCMI 
conforming management stations and management agents SHOULD refer to RFC
2012 (November 1996).  

Note:  As of March 2001, RFC 2012 is being updated for IPv6 support.  


9.1.6.1.  Usage of tcpConnTable

Conformance:  XCMI conforming management agents SHOULD implement the TCP
Connection table for competitive equivalence.  


9.1.7.  IETF MIB-II UDP (Cond Mandatory)

This object group contains four (4) leaf objects (with a fixed instance
qualifier of zero, by IETF SMI rules), one (1) table object, two (2)
index objects, and zero (0) columnar objects.  

Conformance:  XCMI conforming management agents SHOULD implement the UDP
group for competitive equivalence.  

Usage:  For detailed implementation guidance on the UDP group, all XCMI 
conforming management stations and management agents SHOULD refer to RFC
2013 (November 1996).  

Note:  As of March 2001, RFC 2013 is being updated for IPv6 support.  


9.1.7.1.  Usage of udpTable

Conformance:  XCMI conforming management agents SHOULD implement the UDP
Listener table for competitive equivalence.  


9.1.8.  IETF MIB-II EGP (Deprecated)

This object group contains five (5) leaf objects (with a fixed instance
qualifier of zero, by IETF SMI rules), one (1) table object, one (1)
index object, and fourteen (14) columnar objects.  

Conformance:  XCMI conforming management agents SHOULD NOT implement the
Address Translation group, per RFC 1213.  


9.1.9.  IETF MIB-II Transmission (Mandatory)

This object group contains zero (0) leaf objects (with a fixed instance
qualifier of zero, by IETF SMI rules), zero (0) table objects, zero (0)
index objects, zero (0) columnar objects, and one autonoumous object

XCMI Working Group                File 06gentc                 [Page 59]

XCMI General TC V5.601                                     04 April 2007

identifier.  

The OID 'transmission { mib-2 10 }' is the root of transmission media
names for Internet-standard definitions.  

Conformance:  Implementation of the IETF MIB-II Transmission group is
MANDATORY for conformance to the IETF MIB-II.  

Therefore, all XCMI conforming management agents SHALL implement the
IETF MIB-II Transmission group.  


9.1.10.  IETF MIB-II SNMP (Mandatory)

This object group contains twenty-eight (28) leaf objects (with a fixed
instance qualifier of zero, by IETF SMI rules), zero (0) table objects, 
zero (0) index objects, and zero (0) columnar objects.  

Conformance:  Implementation of the IETF MIB-II SNMP group is MANDATORY
for conformance to the IETF MIB-II.  

Therefore, all XCMI conforming management agents SHALL implement the
IETF MIB-II SNMP group.  

Conformance:  All XCMI conforming management agents are STRONGLY
RECOMMENDED to implement a factory default value of 'enabled(1)' for the
'snmpEnableAuthenTraps' object.  All XCMI conforming management agents
are STRONGLY RECOMMENDED to store the value of the
'snmpEnableAuthenTraps' object in non-volatile memory (preserved across
system resets, per RFC 1213).  Failure to preserve the value of
'snmpEnableAuthenTraps' in non-volatile memory will cause highly visible
problems with network management stations in customer environments.  

Usage:  For detailed implementation guidance on the SNMP group, all XCMI
conforming management stations and management agents SHOULD refer to the
SNMP Agent MIB (RFC 1907, January 1996) or its successor.  

Note:  As of October 2001, RFC 1907 is being updated for SNMPv3 and IPv6
support.  
















XCMI Working Group                File 06gentc                 [Page 60]

XCMI General TC V5.601                                     04 April 2007



9.2.  XCMI Supplement to XCMI General MIB

The XCMI conformance requirements for all object groups defined in the
XCMI General MIB (07gen) are listed in the following table:  

Object Group                            XCMI Conformance
------------                            ----------------
General Base                            Mandatory
Current Localization                    Conditionally Mandatory
General Localization                    Conditionally Mandatory
Code Indexed String                     Conditionally Mandatory
Coded Character Set                     Conditionally Mandatory
Fixed Localization                      Conditionally Mandatory
General Lock                            Conditionally Mandatory
General Reconf                          Conditionally Mandatory
General Option                          Conditionally Mandatory
Client Data                             Conditionally Mandatory
Trap Client                             Mandatory
Trap View                               Mandatory
Message Map                             Conditionally Mandatory
Message Text                            Conditionally Mandatory
Notify Rule                             Conditionally Mandatory
Notify Detail                           Conditionally Mandatory

Conformance:  All XCMI conforming management agents, which implement the
General MIB, SHALL implement the General Base, Trap Client, and Trap
View groups in the XCMI General MIB.  

Conformance:  All XCMI conforming management agents, which implement the
General MIB, are STRONLY RECOMMENDED to implement the General Lock group
in the XCMI General MIB, to support Set coordination among cooperating
management stations.  

Conformance:  All XCMI conforming management agents, which implement the
General MIB, SHOULD implement the other object groups as required, to
improve interworking with third-party network management stations and
MIB module snap-in applications.  


9.2.1.  PresentOnOff Persistency

The IETF Printer MIB defines a textual convention called 'PresentOnOff'.
This XCMI General MIB recommends that all objects of type 'PresentOnOff'
be persistent across power cycles.  


9.2.2.  Text Strings and Localization

Unicode:  The IESG now requires MANDATORY support for UTF-8 (IETF RFC
2279 and ISO 10646) in ALL core Internet suite protocols, as specified
in the IETF Policy on Character Sets and Languages (BCP 18, RFC 2277,
January 1998).  

XCMI Working Group                File 06gentc                 [Page 61]

XCMI General TC V5.601                                     04 April 2007


Conformance:  All XCMI conforming management stations AND management
agents SHALL support UTF-8 (IETF RFC 2279 and ISO 10646) in ALL external
protocol interfaces.  

Conformance:  All XCMI conforming management stations AND management
agents SHOULD NOT support the ambiguous Unicode UTF-16 transforms (IETF 
RFC 2781) in ANY external protocol interface, to avoid opportunities for
security breaches and to preserve data integrity.  

Best Current Practice:  The XCMI Editors now recommend that support for 
the 'CodeIndexedStringIndex' type is costly (requires two Gets for any
access and defeats use of SNMPv2 GetBulk entirely), it SHOULD NOT be
used in specifying new MIB modules.  Where STATIC localization is
required (managment station provides message catalogs), use the
'XcmFixedLocaleDisplayString' type instead (minimum cost to management
agent implementors for text strings which still retain a fully specified
'locale', unlike ambiguous strings of 'DisplayString' type).  Where
DYNAMIC localization is required (agent provides message catalogs), use
the 'InternationalDisplayString' type instead.  

All human-readable strings are specified in some 'locale'.  In POSIX.2
(ISO 9945-2), a 'locale' specification consists of a language, a country
(or territory), and a coded character set.  This definition is used in
the IETF Printer MIB (RFC 1759) and throughout the XCMI MIB standards.  
All XCMI MIBs SHALL explicitly specify the size constraints on their
string objects, eg, 'InternationalDisplayString (SIZE (0..255))'.  

The four types of text strings used in IETF, PWG, and XCMI MIBs are as
follows:  

1)  'DisplayString'
    - SHALL NOT be used in new XCMI MIB module definitions
    - SMIv1 definition in IETF MIB-II (RFC 1213)
    - SMIv2 definition in IETF SNMPv2-TC (RFC 2579)
    - locale is unspecified (but implicitly English only)
    Strings that are NOT localized by the management agent and are
    represented in the Network Virtual Terminal (NVT) ASCII code set
    (defined in IETF TELNET, RFC 854).

2.  'InternationalDisplayString'
    - SHALL NOT be used in new XCMI MIB module definitions
    - SMIv1 definition in IETF Host Resources MIB (RFC 2790)
    - locale specified via 'xcmGenCurrentLocalizationIndex' in XCMI
      General MIB (indexed by 'hrDeviceIndex' in IETF HR MIB), an
      XCMI generalization of 'prtGeneralCurrentLocalization' in the
      IETF Printer MIB (RFC 1759)
    Strings that are localized by the management agent according to
    one or more supported DYNAMIC text string locales.  The current
    locale may be updated quite frequently by management stations
    (during normal managed system operation).

3.  'XcmFixedLocaleDisplayString'
    - SHALL be used in new XCMI MIB module definitions

XCMI Working Group                File 06gentc                 [Page 62]

XCMI General TC V5.601                                     04 April 2007

    - SMIv2 definition in XCMI General TC
    - locale specified via 'xcmGenFixedLocalizationIndex' in XCMI
      General MIB (indexed by 'hrDeviceIndex' in IETF HR MIB)
    Strings that are localized by the management agent according to
    one or more supported STATIC text string locales.  The current
    locale is usually updated infrequently by management stations
    (normally ONCE at system install time or system upgrade time).

4.  'CodeIndexedStringIndex'
    - SHALL NOT be used in new XCMI MIB module definitions
    - SMIv2 definition in XCMI General TC
    - locale specified via 'xcmJobSubmittedLocaleIndex' in XCMI Job
      Monitoring MIB for job objects
    - locale specified via 'xcmGenFixedLocalizationIndex' in XCMI
      General MIB for all other relevant objects in XCMI MIBs
    - code set specified via 'xcmGenCodeIndexStringCharSet' in XCMI
      General MIB (low-order after 'xcmGenCodeIndexedStringIndex')
    Strings that are represented in a fixed locale (language and
    country) in one or more code sets by the management agent.
    Management stations may request the DYNAMIC translation of one
    of these strings to a desired code set by specifying the code
    set as the low-order index of an SNMP Get-Request to a row in
    the 'xcmGenCodeIndexedStringTable' in the XCMI General MIB
    (indexed by 'hrDeviceIndex', 'xcmGenCodeIndexedStringIndex', and
    'xcmGenCodeIndexedStringCharSet').


9.2.3.  General Base (Mandatory)

Conformance:  All XCMI conforming management agents, which implement the
General MIB, SHALL implement the General Base group in the XCMI General
MIB.  

Support for efficient discovery by SNMP management stations (clients) of
XCMI General MIB capabilities of SNMP management agent implementations
(on managed systems) is provided by the General Base group.  

This object group contains zero (0) leaf objects (with a fixed instance
qualifier of zero, by IETF SMI rules), one (1) table object, one (1)
index object, and fourteen (14) columnar objects.  

Conformance:  Implementation of the XCMI General MIB General Base group
is MANDATORY for conformance to the XCMI General MIB.  

Therefore, all XCMI conforming management agents SHALL implement the
XCMI General MIB General Base group.  

In the XCMI General MIB, system capabilities information is supported by
the following fifteen columnar objects in the General Base group:  

1)  'xcmGenBaseRowStatus' (row status for this conceptual row);
2)  'xcmGenBaseSystemHrDeviceIndex' (CPU device of this SNMP agent);
3)  'xcmGenBaseGroupSupport' (set of ALL supported groups);
4)  'xcmGenBaseGroupCreateSupport' (set of 'read-create' groups);

XCMI Working Group                File 06gentc                 [Page 63]

XCMI General TC V5.601                                     04 April 2007

5)  'xcmGenBaseGroupUpdateSupport' (set of 'read-write' groups);
6)  'xcmGenBaseClientDataMaxSupport' (max size of client data);
7)  'xcmGenBaseOptionSyntaxSupport' (set of supported option syntaxes);
8)  'xcmGenBaseReconfStateSupport' (set of supported reconf states);
9)  'xcmGenBaseSNMPDomainSupport' (set of supported SNMP domains);
10) 'xcmGenBaseSNMPTrapSupport' (boolean for SNMP trap support);
11) 'xcmGenBaseSNMPVersionSupport' (set of supported SNMP versions);
12) 'xcmGenBaseSNMPReadCommunity' (configured read community name);
13) 'xcmGenBaseSNMPWriteCommunity' (configured write community name);
14) 'xcmGenBaseSNMPTrapCommunity' (configured trap community name);
15) 'xcmGenBaseGroupWalkHidden' (set of MIB walk 'hidden' groups);

Usage:  The 'xcmGenBaseSystemHrDeviceIndex' object specifies the value
of 'hrDeviceIndex' for the CPU device (of type 'hrDeviceProcessor')
which currently supports the executing process/thread of this management
agent (usually the 'main' system CPU).  This object helps management
stations discover which row of the 'xcmGenFixedLocalizationTable'
specifies the installed or updated localization of all strings of type
'XcmFixedLocaleDisplayString'.  

Usage:  The 'xcmGenBaseGroupSupport' object specifies ALL of the
implemented object groups in the XCMI General MIB on this management
agent.  These object groups MAY support 'read-only', 'read-write', or
'read-create' access.  

Usage:  The 'xcmGenBaseGroupCreateSupport' object specifies ONLY the
implemented object groups in the XCMI General MIB on this management
agent which support dynamic rows ('read-create').  Dynamic rows are
created via 'createAndGo(4)' writes to 'xxxRowStatus' and released via
'destroy(6)' writes to 'xxxRowStatus'.  

Usage:  The 'xcmGenBaseGroupUpdateSupport' object specifies ONLY the
implemented object groups in the XCMI General MIB on this management
agent which support 'read-write' access.  Groups which support
'read-write' access have either dynamic rows (see above) or static rows.
Static rows are allocated via 'active(1)' writes to 'xxxRowStatus' and
released via 'notInService(2)' writes to 'xxxRowStatus'.  

Usage:  The 'xcmGenBaseClientDataMaxSupport' object specifies the
maximum length of 'xcmGenClientDataString' (requested via write to
'xcmGenClientDataLength') supported on this management agent.  

Conformance:  Conforming management stations (clients) SHALL NOT request
creation of dynamic rows in 'xcmGenClientDataTable' with a greater
length than specified by 'xcmGenBaseClientDataMaxSupport'.  

Usage:  The 'xcmGenBaseOptionSyntaxSupport' object specifies (in a
bit-mask) the 'xcmGenOptionValueSyntax' values in the
'xcmGenOptionTable' supported on this management agent.  

Usage:  The 'xcmGenBaseReconfStateSupport' object specifies (in a
bit-mask) the 'xcmGenReconfOptionState' values in the
'xcmGenReconfTable' supported on this management agent.  


XCMI Working Group                File 06gentc                 [Page 64]

XCMI General TC V5.601                                     04 April 2007


Conformance:  Conforming management agents NEED NOT support more than
one 'validate...' and 'activate...' operation pair.  

Usage:  The 'xcmGenBaseSNMPDomainSupport' object specifies (in a
bit-mask) the 'xcmGenTrapClientSNMPDomain' values in the
'xcmGenTrapClientTable' supported on this management agent.  

Usage:  The 'xcmGenBaseSNMPTrapSupport' object specifies whether or not
SNMP traps (in any version) are supported on this management agent.  

Usage:  The 'xcmGenBaseSNMPVersionSupport' object specifies (in a
bit-mask) the 'xcmGenTrapClientSNMPVersion' values in the
'xcmGenTrapClientTable' supported on this management agent.  

Usage:  The 'xcmGenBaseSNMPReadCommunity' object specifies a 'read
community name' valid in any SNMPv1c and SNMPv2c read requests received
by this management agent.  

Usage:  The 'xcmGenBaseSNMPWriteCommunity' object specifies a 'write
community name' valid in any SNMPv1c and SNMPv2c write requests received
by this management agent.  

Usage:  The 'xcmGenBaseSNMPTrapCommunity' object specifies a 'trap
community name' valid in all SNMPv1c and SNMPv2c trap and inform PDUs
generated by this management agent, except when
'xcmGenTrapClientSNMPCommunity' specifies an alternate value for a
particular registered trap destination.  

Usage:  The 'xcmGenBaseGroupWalkHidden' object specifies ONLY the
implemented object groups in the XCMI General MIB on this management
agent which are currently 'hidden' for MIB walks.  Such 'hidden' groups
SHALL be skipped over for SNMP GetNext or GetBulk requests.  

See:  SNMPv1c (RFC 1157) and SNMPv2c (RFC 1905) protocol specifications.


9.2.4.  General Localization (Cond Mand)

The General Localization group defines objects to identify the supported
locales for 'InternationalDisplayString', 'xcmFixedLocaleDisplayString',
and 'CodeIndexedStringIndex' text string objects.  Each supported locale
is a tuple of language, country, and code set.  Each supported locale is
identified by a unique value of 'xcmGenLocalizationIndex'.  


9.2.5.  Current Localization (Cond Mand)

The Current Localization group defines objects to control the DYNAMIC
localization of objects of the 'InternationalDisplayString' type.  The
current DYNAMIC locale is specified in 'xcmGenCurrentLocalizationIndex' 
(for each device in the 'hrDeviceTable' of the IETF Host Resources MIB, 
since 'xcmGenCurrentLocalizationTable' is indexed by 'hrDeviceIndex').  


XCMI Working Group                File 06gentc                 [Page 65]

XCMI General TC V5.601                                     04 April 2007


Management stations SHOULD Get 'xcmGenCurrentLocalizationIndex' whenever
they Get objects of type 'InternationalDisplayString', to detect whether
another management station has Set the DYNAMIC locale to a different
value.  If the returned value of the 'xcmGenCurrentLocalizationIndex'
object was not as desired, then the management station may:  1) wait a
random time period and try again, by performing a Set of the value of
'xcmGenCurrentLocalizationIndex' to the desired locale (similar to the
Ethernet collision backoff algorithm); or 2) acquire an 'advisory lock' 
on the 'xcmGenCurrentLocalizationIndex' object via the General Lock
group ('xcmGenLockTable') and then Set the desired locale into
'xcmGenCurrentLocalizationIndex'.  

'InternationalDisplayString' objects may be installed on the managed
host system by means outside SNMP and this MIB.  For example, one such
method is installing additional message catalog files into a special
file system directory on the server.  In such cases, management stations
cannot modify the values of 'InternationalDisplayString' objects and the
management agent SHALL implement them as 'read-only'.  

However, some management agents may wish to allow management stations to
alter the values of 'InternationalDisplayString' objects for supported
locales, by implementing the 'InternationalDisplayString' objects as
'read-write'.  Such an implementation SHALL allow management stations to
Set 'xcmGenCurrentLocalizationIndex' to ANY of the supported locales and
SHALL keep distinct values for an 'InternationalDisplayString' object
for each locale so written.  If a management station writes a different 
value using the same locale, then the management agent SHALL replace the
old value with the new value.  If a management agent is not able to keep
distinct values for a particular 'InternationalDisplayString' object,
one for each supported locale, then the management agent SHALL implement
that 'InternationalDisplayString' object as 'read-only'.  

A higher-end management agent may allow management stations to install
new locales in the management agent, by allowing management stations to 
create new rows in 'xcmGenLocalizationTable', using the 'RowStatus'
mechanism.  In other words, a management station is able to effectively 
store a new message catalog for a new locale, by adding a row to the
'xcmGenLocalizationTable' and writing each 'InternationalDisplayString' 
object with a value appropriate to the new locale.  Management agents
not capable of accepting new rows in the 'xcmGenLocalizationTable' SHALL
implement 'xcmGenLocalizationRowStatus' as 'read-only'.  


9.2.6.  Fixed Localization (Cond Mand)

The Fixed Localization group defines objects to control the STATIC
localization of objects of the 'XcmFixedLocaleDisplayString' type.  The 
current STATIC locale is specified in 'xcmGenFixedLocalizationIndex'
(for each device in the 'hrDeviceTable' of the IETF Host Resources MIB, 
since 'xcmGenFixedLocalizationTable' is indexed by 'hrDeviceIndex').  

The 'xcmGenFixedLocalizationTable' contains information about the static
(or largely static) 'fixed locale' (language, country, code set) of ALL 

XCMI Working Group                File 06gentc                 [Page 66]

XCMI General TC V5.601                                     04 April 2007

string objects of type 'XcmFixedLocaleDisplayString' and (optionally) of
selected string objects of type 'CodedIndexedStringIndex' (for XCMI MIB 
objects), 'DisplayString' (for IETF MIB objects), or 'OCTET STRING' (for
legacy IETF and vendor MIB objects).  


9.2.6.1.  Rationale for Fixed Locale Strings

XCMI conforming management stations may need to access 'human-readable' 
string objects in XCMI MIBs, for which dynamic localization would be
costly to implement, in addition to those string objects (of type
'InternationalDisplayString'), for which dynamic localization support is
mandatory (for XCMI conforming management agents).  

Therefore, the concept of 'fixed locale' string objects is introduced to
permit the definition of XCMI MIB string objects subject to static (or
essentially static) localization.  Each configured device (in the
'hrDeviceTable' of the IETF Host Resources MIB, RFC 2790) on a managed
host system, may support a single current fixed locale (or none).  

Many XCMI MIB objects exist primarily (if not solely) for human end user
convenience.  Therefore, it becomes highly desirable for management
stations which are accessing such fixed locale string objects to have an
efficient and reliable means of determining their static (or essentially
static) fixed locales (eg, in order to perform code set or language
conversions, as appropriate).  


9.2.6.2.  Management Station/Agent Conformance

XCMI conforming management stations and management agents SHALL apply
the fixed locale (current value of 'xcmGenFixedLocalizationIndex' for
each device in the 'hrDeviceTable' of the IETF Host Resources MIB) to
ALL strings of type 'XcmFixedLocaleDisplayString'.  

XCMI conforming management stations and management agents may ALSO apply
the fixed locale (current value of 'xcmGenFixedLocalizationIndex' for
each device in the 'hrDeviceTable' of the IETF Host Resources MIB) to
selected strings of type 'CodeIndexedStringIndex' (for XCMI MIB
objects), 'DisplayString' (for IETF MIB objects), or 'OCTET STRING' (for
legacy IETF and vendor MIB objects), by bi-lateral agreement with their 
correspondent XCMI conforming management stations and management agents.

XCMI conforming management stations and management agents SHALL NOT
violate the fixed locale (language, country, code set) requirements
which apply to ANY string object.  They SHALL NOT write (Set) any value 
to such a string object which violates the fixed locale.  They SHALL NOT
read (Get) any value from such a string object, without interpreting it 
according to the fixed locale.  






XCMI Working Group                File 06gentc                 [Page 67]

XCMI General TC V5.601                                     04 April 2007



9.2.7.  Code Indexed String (Cond Mand)

Best Current Practice:  The XCMI Editors now recommend that support for 
the 'CodeIndexedStringIndex' type is costly (requires two Gets for any
access and defeats use of SNMPv2 GetBulk entirely), it SHOULD NOT be
used in specifying new MIB modules.  Where STATIC localization is
required (managment station provides message catalogs), use the
'XcmFixedLocaleDisplayString' type instead (minimum cost to management
agent implementors for text strings which still retain a fully specified
'locale', unlike ambiguous strings of 'DisplayString' type).  Where
DYNAMIC localization is required (agent provides message catalogs), use
the 'InternationalDisplayString' type instead.  

The Code Indexed String group provides objects to control the code set
(but NOT the language or country elements of 'locale') of objects of
type 'CodeIndexedStringIndex'.  The XCMI General MIB defines a single,
'xcmGenCodeIndexedStringTable', with a first index of 'hrDeviceIndex'
(from the IETF Host Resources MIB, RFC 2790), a second index of
'xcmGenCodeIndexedStringIndex' (the immediate value of objects of type
'CodeIndexedStringIndex'), and third index of type 'CodedCharSet', the
coded character set enum registered by IANA (see the 'CodedCharSet'
textual convention in the IETF Printer MIB, RFC 1759).  The IANA
character set registry primary copy is at:  

ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 

Thus the management station can request any supported coded character
set from the management agent.  The management agent either has the
string stored locally or performs 'on the fly' charset conversion to the
supported character sets.  

The management station must first Get 'CodeIndexedStringIndex' objects
and then perform a second Get, specifying the returned index and the
coded character enum desired by the management station (from among the
sets supported by the management agent).  If a management station
requests a coded character set that the management agent doesn't
support, the management agent SHALL return an error consistent with the 
SNMP protocol version in use, indicating that the object (or instance)
is not present.  

Example:  The 'xcmJobName' object is of type 'CodeIndexedStringIndex'.  
Assume it contains the index value 500.  Let's also assume that the
'hrDeviceIndex' value is 1, so that the printer in question is the 1st
row in the 'hrDeviceTable'.  Finally, assume that the management agent
supports US-ASCII, ISO Latin1, and UTF-8 (IETF RFC 2279 and ISO 10646)
which have registered IANA charset registry enum values of 3, 4, and
106, respectively.  The management agent will appear to store
'xcmJobName' objects in the 'xcmGenCodedIndexedStringTable' that the
management station accesses by the following indices:  

    { 1, 500, 3 }
    { 1, 500, 4 }

XCMI Working Group                File 06gentc                 [Page 68]

XCMI General TC V5.601                                     04 April 2007

    { 1, 500, 106 }

The management agent need not actually have all representations of a
'CodeIndexedStringIndex' object stored, but may charset convert to the
requested coded character set 'on the fly' in response to the Get
operation, depending on which of the coded character sets the management
station actually requested.  Thus in the example above, the agent may
only store the 'xcmJobName' object value as UTF-8 { 10, 500, 106 } and
convert to ASCII { 10, 500, 3 } or ISO Latin1 { 10, 500, 4 } when it
receives a request from a management station.  

In order to help a management station discover the coded character sets 
supported for 'CodeIndexedStringIndex' objects, the XCMI General MIB
defines 'xcmGenCodedCharSetTable', which contains the enums of the
character sets registered with IANA that the management agent supports, 
either directly or with charset conversion, along with a name and
description of each coded character set.  


9.2.7.1.  Charset Conversions using CodeIndexedString

Unicode:  The IESG now requires MANDATORY support for UTF-8 (IETF RFC
2279 and ISO 10646) in ALL core Internet suite protocols, as specified
in the IETF Policy on Character Sets and Languages (BCP 18, RFC 2277,
January 1998).  

Conformance:  All XCMI conforming management stations AND management
agents SHALL support UTF-8 (IETF RFC 2279 and ISO 10646) in ALL external
protocol interfaces.  

Conformance:  All XCMI conforming management stations AND management
agents SHOULD NOT support the ambiguous Unicode UTF-16 transforms (IETF 
RFC 2781) in ANY external protocol interface, to avoid opportunities for
security breaches and to preserve data integrity.  

Each 'CodeIndexedStringIndex' object SHALL reference a string of at
least one of the following coded character sets:  

    UTF-8 transform of ISO 10646 UCS-4 level 3 (full Unicode 3.0)
    ASCII (X3.4-1968, NVT ASCII)
    ISO Latin1 (ISO 8859-1)
    T61String (ITU/CCITT text communication which contains JIS 6226)

All XCMI conforming management agents SHALL perform charset conversions 
from a source coded character set to a destination coded character set
in strict conformance with the Xerox Unicode Coherence Standard and the 
Xerox Locale Coherence Standard.  

To help a management station that wants to avoid getting too many
approximations or error characters, the management station can query the
agent to determine the coded character set that was used to submit a
job.  The 'xcmJobSubmittedLocaleIndex' contains the 'locale' (language,
country, and coded characters set) used by the submitting client for
attributes of type 'CodeIndexedStringIndex'.  The management station can

XCMI Working Group                File 06gentc                 [Page 69]

XCMI General TC V5.601                                     04 April 2007

then request the data using that original character set (if the
management client supports that character set or prefers to perform its
own coded character set conversion, rather than relying on the agent to
perform the coded character set conversion).  

XCMI MIB objects SHALL support a maximum of 255 octets for coded
character set data (while the ISO DPA standard requires support for a
maximum of 4095 octets).  This XCMI MIB object limit is specified for
all OCTET STRING base type objects in IETF SMIv1 and SMIv2 standards.  














































XCMI Working Group                File 06gentc                 [Page 70]

XCMI General TC V5.601                                     04 April 2007



9.2.8.  General Lock (Cond Mand)

The XCMI General MIB contains a mechanism for support of 'advisory
contention locks' for various subtrees of MIB objects from the complete 
set of IETF and XCMI MIB modules implemented by a given host system; and
support of a generalized reconfiguration mechanism for all MIB objects
from the complete set of IETF and XCMI MIB modules implemented by a
given host system.  

Conformance:  All XCMI conforming management agents, which implement the
General MIB, are STRONLY RECOMMENDED to implement the General Lock group
in the XCMI General MIB, to support Set coordination among cooperating
management stations.  



9.2.8.1.  Use of Advisory Locks in XCMI

An 'advisory lock' is a contention lock used by an interested community 
of cooperating management stations and a managed host system's local
management agent.  An XCMI 'advisory lock' is implemented via an 'owner 
string' (see note below), an 'owner subtree' (supporting branch-level
locking of the object identifier namespace within a managed system), and
an 'owner timer' (supporting advice to contending management stations as
to the MAXIMUM duration of a given lock).  Both of these latter two
objects are XCMI enhancements to the original IETF 'advisory lock'
mechanism (eg, in RFC 2233).  

Note:  As specified in SMIv2 TC (RFC 1443/1903/2579), an 'owner string' 
SHALL contain one or more of the following:  
a)  Textual form of the management station's transport address;
b)  Management station name (eg, domain name); and/or
c)  Network management person's name, location or phone.
In the instance that the management agent itself is the 'owner', the
'owner string' object SHALL be set to a string beginning with 'agent'
(in English).  

In the XCMI General MIB, the 'advisory lock' mechanism is supported by
the following five simple objects in the General Lock group:  

1)  'xcmGenLockSupportMaxTimer' (longest timer supported by agent);
2)  'xcmGenLockCurrentMaxTimer' (longest currently active timer);
3)  'xcmGenLockCurrentLockCount' (count of currently 'active' rows);
4)  'xcmGenLockHighestLockIndex' (highest row index ever used);
5)  'xcmGenLockSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, the 'advisory lock' mechanism is supported by
the following five columnar objects in the General Lock group:  

1)  'xcmGenLockIndex' (instance identifier of this row);
2)  'xcmGenLockRowStatus' (for acquire/release of this row);
3)  'xcmGenLockOwnerString' (specifies the owner of this row);

XCMI Working Group                File 06gentc                 [Page 71]

XCMI General TC V5.601                                     04 April 2007

4)  'xcmGenLockOwnerSubtree' (specifies the 'scope' of this row);
5)  'xcmGenLockOwnerTimer' (specifies remaining duration of this row).





















































XCMI Working Group                File 06gentc                 [Page 72]

XCMI General TC V5.601                                     04 April 2007



9.2.8.2.  Acquiring an Advisory Lock (Dynamic Rows)

For managed systems which support dynamic rows (via 'createAndGo' and
'destroy'), to acquire an 'advisory lock' on a particular subtree in the
managed system, a remote management station (or the local management
agent) SHALL perform the following steps:  

1)  Get (read), in a single SNMP PDU, 'xcmGenLockSupportMaxTimer'
    (optional, but useful), 'xcmGenLockSupportMaxCount' (optional, but
    useful), 'xcmGenLockCurrentLockCount' (optional, but useful), and
    'xcmGenLockHighestLockIndex' (required); 
    
2)  Add one to the returned value of 'xcmGenLockHighestLockIndex', to
    derive a suitable value (instance identifier) for 'xcmGenLockIndex',
    to permit creation of a new row in the 'xcmGenLockTable'; 
    
3)  Set (write), in a single SNMP PDU, 'xcmGenLockRowStatus' to
    'createAndGo(4)', 'xcmGenLockOwnerString' to a suitable value (see
    note above), 'xcmGenLockOwnerSubtree' to a suitable value (ie, the
    desired 'scope' in the namespace of the managed system); and
    'xcmGenLockOwnerTimer' to the MAXIMUM time (in seconds) for which
    the management station (or local management agent) wishes to retain 
    the 'advisory lock'; 
    
4)  If the Set (write) completes without error, the 'advisory lock' has 
    been acquired - otherwise, continue at step (1) above (after DELAY, 
    if error is 'inconsistentValue' for 'xcmGenLockOwnerSubtree').  


























XCMI Working Group                File 06gentc                 [Page 73]

XCMI General TC V5.601                                     04 April 2007



9.2.8.3.  Acquiring an Advisory Lock (Static Rows)

For managed systems which support static rows (via 'active' and
'notInService'), to acquire an 'advisory lock' on a particular subtree
in the managed system, a remote management station (or the local
management agent) SHALL perform the following steps:  

1)  Get (read), in a single SNMP PDU, 'xcmGenLockSupportMaxTimer'
    (optional, but useful), 'xcmGenLockSupportMaxCount' (optional, but
    useful), and 'xcmGenLockCurrentLockCount' (optional, but useful); 
    
2)  GetNext (read), 'xcmGenLockRowStatus' until a row is found in the
    'notInService(2)' state and select this row for use by saving the
    returned value of 'xcmGenLockIndex' as a suitable value (instance
    identifier) to permit allocation of an existing row in the
    'xcmGenLockTable'; 
    
3)  Set (write), in a single SNMP PDU, 'xcmGenLockRowStatus' to
    'active(1)', 'xcmGenLockOwnerString' to a suitable value (see note
    above), 'xcmGenLockOwnerSubtree' to a suitable value (ie, the
    desired 'scope' in the namespace of the managed system); and
    'xcmGenLockOwnerTimer' to the MAXIMUM time (in seconds) for which
    the management station (or local management agent) wishes to retain 
    the 'advisory lock'; 
    
4)  If the Set (write) completes without error, the 'advisory lock' has 
    been acquired - otherwise, continue at step (1) above (after DELAY, 
    if error is 'inconsistentValue' for 'xcmGenLockOwnerSubtree').  

























XCMI Working Group                File 06gentc                 [Page 74]

XCMI General TC V5.601                                     04 April 2007



9.2.8.4.  Releasing an Advisory Lock (Dynamic Rows)

For managed systems which support dynamic rows (via 'createAndGo' and
'destroy'), to release an 'advisory lock' on a particular subtree in a
managed system, the 'owner' management station (or local management
agent) SHALL perform the following steps:  

1)  Set (write), in a single SNMP PDU, 'xcmGenLockRowStatus' to the
    value 'destroy(6)'; 
    
2)  If the Set (write) completes without error, the 'advisory lock' has 
    been released normally - otherwise, the local management agent MAY
    have released the 'advisory lock' due to timeout or other local
    conditions - in any event, the 'advisory lock' SHOULD now have been 
    released.  


9.2.8.5.  Releasing an Advisory Lock (Static Rows)

For managed systems which support static rows (via 'active' and
'notInService'), to release an 'advisory lock' on a particular subtree
in a managed system, the 'owner' management station (or local management
agent) SHALL perform the following steps:  

1)  Set (write), in a single SNMP PDU, 'xcmGenLockRowStatus' to the
    value 'notInService(2)'; 
    
2)  If the Set (write) completes without error, the 'advisory lock' has 
    been released normally - otherwise, the local management agent MAY
    have released the 'advisory lock' due to timeout or other local
    conditions - in any event, the 'advisory lock' SHOULD now have been 
    released.  





















XCMI Working Group                File 06gentc                 [Page 75]

XCMI General TC V5.601                                     04 April 2007



9.2.8.6.  Acquiring ENTIRE System Lock

elegant mechanism.] 

To acquire an 'advisory lock' on ALL subtrees in an ENTIRE managed
system, a given management station (or the local management agent) SHALL
ALWAYS perform the following steps:  

1)  Get (read), in a single SNMP PDU, 'xcmGenLockCurrentMaxTimer' and
    'xcmGenLockHighestLockIndex' (if dynamic rows are supported); 
    
2)  Add a suitable delta to 'xcmGenLockCurrentMaxTimer' (for eventual
    useful processing work, once the ENTIRE managed system lock becomes 
    EXCLUSIVE), to derive a suitable value for 'xcmGenLockOwnerTimer'; 
    
3a) For managed systems which support dynamic rows (via 'destroy'), add
    one to the returned value of 'xcmGenLockHighestLockIndex', to derive
    a suitable value (instance identifier) for 'xcmGenLockIndex', to
    permit creation of a new row in the 'xcmGenLockTable'; 
    
3b) For managed systems which support static rows (via 'notInService'), 
    GetNext (read), 'xcmGenLockRowStatus' until a row is found in the
    'notInService(2)' state and select this row for use by saving the
    returned value of 'xcmGenLockIndex' as a suitable value (instance
    identifier) to permit allocation of an existing row in the
    'xcmGenLockTable'; 
    
4)  Lock the 'xcmGenLockTable' ITSELF (using the procedure described in 
    the above section 'Acquiring an Advisory Lock'); 
    
5)  Poll via Get (read), 'xcmGenLockCurrentLockCount'; 
    
6)  When 'xcmGenLockCurrentLockCount' decrements to one (1), the ENTIRE 
    managed system lock has become EXCLUSIVE (ie, no other contending
    management station is capable of acquiring any subtree lock).  

















XCMI Working Group                File 06gentc                 [Page 76]

XCMI General TC V5.601                                     04 April 2007



9.2.8.7.  Management Agent Conformance

Conformance:  An XCMI conforming management agent SHALL ensure that an
'advisory lock' is NOT granted for:  

1)  Any object identifier subtree which is within the 'scope' of an
    existing lock 'higher' in the object identifier tree; or 
    
2)  Any object identifier subtree which contains the 'scope' of an
    existing lock 'lower' in the object identifier tree.  

Conformance:  Conforming management agents SHALL NOT accept sets to 
'xcmGenLockOwnerString', or
'xcmGenLockOwnerSubtree'
AFTER row creation (these objects are 'write-once').  


9.2.8.8.  Management Station Conformance

Conformance:  An XCMI conforming management station SHALL ensure that:  

1) All existing managed system 'advisory locks' SHALL be honored (see
    below); 
    
2) All managed system reconfiguration is performed ONLY after acquiring 
    the relevant 'advisory lock(s)'.  

Conformance:  An XCMI conforming management station MAY choose to
increase or reduce the value of 'xcmGenLockOwnerTimer', subsequent to
dynamic row creation or static row allocation, for example to 'refresh' 
the timer for an additional time interval.  

Conformance:  An XCMI conforming management station SHALL NOT reduce the
value of 'xcmGenLockOwnerTimer' to zero (as an indirect 'destroy'
operation).  An XCMI conforming management agent SHALL reject any such
set to zero of this owner lock timer.  

Conformance:  Conforming management stations, when they first create or 
activate rows in this table, SHALL set 
'xcmGenLockRowStatus' to 'active(1)' (for static rows) or
'createAndGo(4)' (for dynamic rows),
'xcmGenLockOwnerString' (if an owner string is available),
'xcmGenLockOwnerSubtree' (if not 'zeroDotZero'), and
'xcmGenLockOwnerTimer' (to a suitable value)
SIMULTANEOUSLY (in the same SNMP Set-Request PDU).  








XCMI Working Group                File 06gentc                 [Page 77]

XCMI General TC V5.601                                     04 April 2007



9.2.9.  General Reconf and General Option (Cond Mand)

The XCMI General MIB contains a mechanism for support of orderly and
atomic reconfiguration (of arbitrary complexity) across multiple objects
in multiple MIB modules.  

In the XCMI General MIB, the 'reconfiguration set' mechanism is
supported by the following three simple objects in the General Reconf
group:  

1)  'xcmGenReconfActivations' (count of successful reconfigurations);
2)  'xcmGenReconfEntryCount' (count of currently 'active' rows);
3)  'xcmGenReconfSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, the 'reconfiguration set' mechanism is
supported by the following six columnar objects in the General Reconf
group:  

1)  'xcmGenReconfIndex' (instance identifier of this row);
2)  'xcmGenReconfRowStatus' (for acquire/release of this row);
3)  'xcmGenReconfOptionIndex' (first option 'active' in this set);
4)  'xcmGenReconfOptionState' (reconfiguration command or state);
5)  'xcmGenReconfErrorIndex' (first option 'in error' in this set);
6)  'xcmGenReconfErrorStatus' (first option error status in this set).

In the XCMI General MIB, the 'reconfiguration set' mechanism is
supported by the following two simple objects in the General Option
group:  

1)  'xcmGenOptionEntryCount' (count of currently 'active' rows);
2)  'xcmGenOptionSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, the 'reconfiguration set' mechanism is
supported by the following twelve columnar objects in the General Option
group:  

1)  'xcmGenOptionIndex' (instance identifier of this row);
2)  'xcmGenOptionRowStatus' (for acquire/release of this row);
3)  'xcmGenOptionTypeOID' (type of this option, eg, from Comms Config);
4)  'xcmGenOptionValueSyntax' (syntax of this option);
5)  'xcmGenOptionValueInteger' (value of this option as integer);
6)  'xcmGenOptionValueOID' (value of this option as OID);
7)  'xcmGenOptionValueString' (value of this option as string);
8)  'xcmGenOptionValueLocalization' (exception locale of this option);
9)  'xcmGenOptionValueCodedCharSet' (exception charset of this option);
10) 'xcmGenOptionNextIndex' (index of next peer option);
11) 'xcmGenOptionPreviousIndex' (index of previous peer option);
12) 'xcmGenOptionFamilyIndex' (index of subordinate option).





XCMI Working Group                File 06gentc                 [Page 78]

XCMI General TC V5.601                                     04 April 2007



9.2.9.1.  Use of Reconfiguration Sets in XCMI

XCMI conforming management stations may accomplish orderly and atomic
reconfiguration (of arbitrary complexity) across multiple objects in
multiple MIB modules, by performing the following steps:  

1)  Acquire 'ownership' of the 'advisory lock' on the appropriate OID
    subtrees on this managed system (see section 'Use of Advisory Locks 
    in XCMI' in this XCMI General TC); 
    
2)  Build an ordered 'graph' of reconfiguration options, by creating new
    rows in the General Option table of the General MIB, using the
    mechanism of the SMIv2 'RowStatus' textual convention (see RFC
    1443/1903/2579) 
    - link the 'graph' of reconfiguration options together via the
    'xcmGenOption[Next|Previous|Family]Index' objects ('next/previous'
    for loosely coupled options and 'family' for tightly coupled or
    dependent options); 
    
3)  Request 'validation' of the complete set of pending reconfiguration 
    options by setting the 'xcmGenReconfOptionState' object to
    'validateFor[ImmediateChange|RebootChange|ImmediateReboot]'; 
    
4)  Wait for the completion of the 'validation', by polling the
    'xcmGenReconfOptionState' object, and watching for a transition to
    'idle' state; 
    
5)  Examine the contents of the 'xcmGenReconfErrorIndex' and
    'xcmGenReconfErrorStatus' objects to verify the success or failure
    of the 'validation'; 
    
6)  If the 'validation' was successful, 'xcmGenReconfErrorIndex' will be
    zero ('0') and 'xcmGenReconfErrorStatus' will be 'noError(0)' 
    - otherwise, 'xcmGenReconfErrorIndex' will point to the first
    reconfiguration option found to be in error and
    'xcmGenReconfErrorStatus' will indicate the nature of the error 
    - correct the reconfiguration option error and continue at step (3) 
    above; 
    
7)  Request 'activation' of the complete set of reconfiguration options 
    by setting the 'xcmGenReconfOptionState' object to
    'activateFor[ImmediateChange|RebootChange|ImmediateReboot]'; 
    
8)  Wait for the completion of the 'activation', by polling the
    'xcmGenReconfOptionState' object, and watching for a transition to
    'idle' state; 
    
9)  Examine the contents of the 'xcmGenReconfErrorIndex' and
    'xcmGenReconfErrorStatus' objects to verify the success or failure
    of the 'activation' (see important note below); 
    


XCMI Working Group                File 06gentc                 [Page 79]

XCMI General TC V5.601                                     04 April 2007

10) If the 'activation' was successful, 'xcmGenReconfErrorIndex' will be
    zero ('0') and 'xcmGenReconfErrorStatus' will be 'noError(0)' 
    - otherwise, 'xcmGenReconfErrorIndex' will point to the first
    reconfiguration option found to be in error and
    'xcmGenReconfErrorStatus' will indicate the nature of the error 
    - correct the reconfiguration option error and continue at step (3) 
    above; 
    
11) Release 'ownership' of the 'advisory lock' on the OID subtrees on
    this managed system.  

Note:  'Activation' by an XCMI conforming management agent SHALL
succeed, if an immediately previous successful 'validation' (of the same
type) has been performed - ANY other behavior would completely preclude 
deterministic reconfiguration by XCMI conforming management stations and
SHALL be avoided.  


9.2.9.2.  Validation Algorithm for Reconfiguration

Please read the detailed explanations of the required and permitted
behavior (at 'XcmGenReconfOptionState' in the General TC) for the three
forms of reconfiguration 'validation'.  

Note:  XCMI conforming management agents NEED NOT support more than one 
of the three forms of reconfiguration 'validation'.  

XCMI conforming management agents SHALL perform 'validation' of the
graph rooted at 'xcmGenReconfOptionIndex' as follows:  

1) Set 'xcmGenReconfErrorIndex' to zero ('0') and set
    'xcmGenReconfErrorStatus' to 'noError(0)' 
    - then proceed to the first node (ie, 'xcmCommsOptionEntry') via the
    pointer in 'xcmGenReconfOptionIndex'; 
    
2) Perform 'validation' of this node (ie, 'xcmCommsOptionEntry') 
    - if error found, report in 'xcmGenReconfError[Index|Status]' and
    exit from the 'validateInProgress' state to the 'idle' state (in
    'xcmGenReconfOptionState') - else, continue at step (3) below; 
    
3)  If 'xcmCommsOptionFamilyIndex' is non-zero, follow the 'shelf'
    horizontally to the next node, and continue at step (2) above 
    - else, continue at step (4) below; 
    
4)  If 'xcmCommsOptionNextIndex' is non-zero, follow the 'chain'
    vertically to the next node, and continue at step (2) above 
    - else, continue at step (5) below; 
    
5)  'Rewind' horizontally to the previous node (if any) on the current
    'shelf', and continue at step (6) below; 
    
6)  If 'xcmCommsOptionFamilyIndex' is non-zero, continue at step (4)
    above 


XCMI Working Group                File 06gentc                 [Page 80]

XCMI General TC V5.601                                     04 April 2007

    - else, exit normally from the 'validateInProgress' state to the
    'idle' state (in 'xcmGenReconfOptionState').  


9.2.9.3.  Activation Behavior for Reconfiguration

Please read the detailed explanations of the required and permitted
behavior (at 'XcmGenReconfOptionState' in the General TC) for the three
forms of reconfiguration 'activation'.  

Note:  XCMI conforming management agents NEED NOT support more than one 
of the three forms of reconfiguration 'activation'.  

XCMI conforming management agents are STRONGLY RECOMMENDED to consider
secure alternatives (eg, use of the Deivce Mgmt group in the XCMI Host
Resources Extensions MIB) for system reset, RATHER than permitting free 
access to the immediate reboot which is invoked by a successful
'activateForImmediateReboot'.  





































XCMI Working Group                File 06gentc                 [Page 81]

XCMI General TC V5.601                                     04 April 2007



9.2.10.  Client Data (Cond Mand)

The 'xcmGenClientDataTable' contains non-volatile 'client data' storage 
areas on the managed device for use by conforming management stations,
particularly during the installation and setup of network accessible
devices.  In order to maintain good management practice, the contents of
these 'client data' areas SHALL each be used and understood only by the 
acquiring management station or management application, and SHALL be
completely opaque to all other conforming managers and to all conforming
management agents and managed devices.  

Only two valid underlying purposes for use of the client data areas have
been identified:  

1)  To provide non-volatile storage to management stations which may
    lack their own such storage;

2)  To provide shared, common storage to the execution-instances of a
    management application which may run on multiple management
    stations or be resumed after suspension on a single management
    station.

In the XCMI General MIB, the 'client data' mechanism is supported by the
following three simple objects in the Client Data group:  

1)  'xcmGenClientDataEntryCount' (count of currently 'active' rows);
2)  'xcmGenClientDataLastIndex' (highest row index ever used);
3)  'xcmGenClientDataSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, the 'client data' mechanism is supported by the
following seven columnar objects in the Client Data group:  

1)  'xcmGenClientDataIndex' (instance identifier of this row);
2)  'xcmGenClientDataRowStatus' (for acquire/release of this row);
3)  'xcmGenClientDataRequestDate' (set by management agent);
4)  'xcmGenClientDataRequestID' (unique ID to identify this row);
5)  'xcmGenClientDataProductID' (unique ID to identify client app);
6)  'xcmGenClientDataLength' (length of client data requested/granted);
7)  'xcmGenClientDataString' (client data - opaque to management agent).


9.2.10.1.  Rationale for Client Data Areas

XCMI conforming management stations may need to perform lengthy and
complex 'device installation' and 'device upgrade' procedures in
unreliable network environments.  Management stations may themselves be 
hosted on platforms of only modest reliability.  Therefore, it becomes
highly desirable for management stations which are performing such
remote 'device administration' procedures to periodically 'checkpoint'
their operational phases on the target network device itself, in order
that those management stations may recover gracefully from any of the
following network service interruptions:  

XCMI Working Group                File 06gentc                 [Page 82]

XCMI General TC V5.601                                     04 April 2007


1)  The 'crash' of any management station, which is currently performing
    remote 'device administration' procedures;

2)  The 'crash' of any router (or other relevant intermediate system),
    which is necessary for remote 'device administration' data packet
    forwarding; or

3)  The 'crash' of a given network device, which is currently the target
    of remote 'device administration' procedures.

The configuration of a network device may be quite complex; it may
involve many steps with significant time duration; it may involve the
configuration of many different network ports on the target network
device (eg, parallel, serial, Ethernet, TokenRing, ATM, FDDI, ISDN, etc)
and their associated protocol stacks (eg, Internet, NetWare, AppleTalk, 
etc); it may involve the setting of various limits, timers, options,
etc, of subsystems attached to or imbedded in the target network device;
it may involve the downloading of various fonts, forms, logos, etc,
which are necessary 'resources' (in the sense used by ISO DPA, ISO/IEC
10175) for the normal operation of the target network device.  

The final aspect of the rationale for support of 'client data' areas by 
network devices, is that the intermediate states and phases of a given
remote 'device administration' procedure are meaningful ONLY to one
particular management station application and are NOT subject (at the
present time) to XCMI or other cross-product standardization.  Note that
cooperating management stations may wish to confirm that one of their
'siblings' has already started (or completed) a given remote 'device
administration' procedure.  


9.2.10.2.  Acquiring a Client Data Area

To acquire a 'client data' area on a managed system, XCMI conforming
management stations SHALL perform the following steps:  

1)  Get (read), in a single SNMP PDU, 'xcmGenClientDataEntryCount'
    (optional, but useful) and 'xcmGenClientDataLastIndex' (required);

2)  Add one to the returned value of 'xcmGenClientDataLastIndex', to
    derive a value (instance identifier) for 'xcmGenClientDataIndex',
    to permit creation of a new row in the 'xcmGenClientDataTable';

3)  Set (write), in a single SNMP PDU, 'xcmGenClientDataRowStatus' to
    'createAndGo(4)', 'xcmGenClientDataRequestDate' to the current date
    and time, 'xcmGenClientDataRequestID' to an 'XcmGlobalUniqueID',
    'xcmGenClientDataProductID' to the 'ProductID' of the client
    (management station) software, and 'xcmGenClientDataLength' to the
    requested length of 'xcmGenClientDataString';

4)  If the Set (write) completes without error, the 'client data' area
    has been acquired - otherwise, the operation was unsuccessful for
    some reason (eg, returned SNMPv2 'error-status' of 'noCreation(11)'

XCMI Working Group                File 06gentc                 [Page 83]

XCMI General TC V5.601                                     04 April 2007

    due to a low memory condition on the managed system).


9.2.10.3.  Releasing a Client Data Area

To release a 'client data' area on a managed system, XCMI conforming
management stations SHALL perform the following steps:  

1)  Set 'xcmGenClientDataRowStatus' to 'destroy(6)';

2)  If the Set (write) completes without error, the 'client data' has
    been released normally - otherwise, the local management agent MAY
    have suffered a loss of system integrity.


9.2.10.4.  Management Agent Conformance

Throughout this specification, the term 'stable storage' refers to
storage which is reliable over long durations (years) and is NOT
destroyed by host system reboot (eg, battery-backed DRAM is 'stable
storage' - while simple DRAM is NOT 'stable storage').  Examples of
valid 'stable storage' include:  NVRAM, hard disk, EEPROM, etc.  

XCMI conforming management agents SHALL preserve active 'client data'
objects across management agent power cycles, and SHALL implement one of
the following two methods:  

1)  The agent SHALL store 'client data' objects directly in
    'stable storage'; or
2)  The agent SHALL automatically checkpoint all active 'client
    data' objects to 'stable storage' with reasonable frequency
    (either due to a write to some 'client data' object, or upon
    expiration of a product-specific timeout).

XCMI conforming management agents may (optionally) implement one of the 
following two 'checkpoint protocols':  

1)  A client sends a 'Set' of 'xcmGenClientDataRowStatus' to
    'active(1)', to request that a 'checkpoint' be performed;
2a) An agent which supports 'rapid checkpoint',
    completes the checkpoint to 'stable storage', and
    sends a 'SetResponse' with 'noError(0)';
    <or>
2b) An agent which supports 'delayed checkpoint',
    changes 'xcmGenClientDataRowStatus' to 'notInService(2)',
    sends a 'SetResponse' with 'noError(0)',
    completes the checkpoint to 'stable storage', and
    changes 'xcmGenClientDataRowStatus' back to 'active(1)'.

Conformance:  Conforming management agents SHALL NOT accept sets to 
'xcmGenClientDataRequestID',
'xcmGenClientDataProductID', or
'xcmGenClientDataLength'


XCMI Working Group                File 06gentc                 [Page 84]

XCMI General TC V5.601                                     04 April 2007

AFTER row creation (these objects are 'write-once').  


9.2.10.5.  Management Station Conformance

XCMI conforming management stations SHALL conserve storage resources on
management agents, and SHALL promptly release any 'client data' areas
which are no longer required.  

XCMI conforming management stations SHOULD perform a Get of
'xcmGenClientDataRowStatus', after requesting a 'checkpoint', to ensure 
that any 'delayed checkpoint' has completed successfully.  

Conformance:  Conforming management stations, when they first create or 
activate rows in this table, SHALL set 
'xcmGenClientDataRowStatus' to 'active(1)' (for static rows) or
'createAndGo(4)' (for dynamic rows),
'xcmGenClientDataRequestID' (to a suitable client global ID),
'xcmGenClientDataProductID' (to a suitable client product ID),
'xcmGenClientDataLength' (to a suitable client data length)
SIMULTANEOUSLY (in the same SNMP Set-Request PDU).  


































XCMI Working Group                File 06gentc                 [Page 85]

XCMI General TC V5.601                                     04 April 2007



9.2.11.  Trap Client and Trap View (Mandatory)

Conformance:  All XCMI conforming management agents, which implement the
General MIB, SHALL implement the Trap Client and Trap View groups in the
XCMI General MIB.  

SNMP version-independent and transport-independent SNMP trap client
(destination) and trap view (object subtree) registration facilities are
provided in the Trap Client and Trap View groups of the XCMI General
MIB.  The Trap Client group is a simplified subset of the Party group in
the Historic SNMPv2 Party MIB (RFC 1447).  The Trap View group is a
simplified subset of the View group in the Historic SNMPv2 Party MIB
(RFC 1447).  

Conformance:  Conforming management stations SHALL create at least one
subordinate row in the 'xcmGenTrapViewTable' for each trap client that
they register in the 'xcmGenTrapClientTable'.  Conforming management
agents SHOULD interpret a dangling row in the 'xcmGenTrapClientTable'
(no children) as 'NO traps in view' (existing implementations of both
clients and devices are known to consider dangling rows invalid).  To
register for all device traps, use a single view of
'iso(1).org(3).dod(6).internet(1)'.  

Conformance:  Conforming management stations are STRONGLY RECOMMENDED to
support 'nonvolatile(4)' in 'xcmGenTrapClientRowPersistence', to improve
interworking with third-party network management stations and MIB module
snap-in applications.  

Conformance:  Conforming management stations, when they first create new
rows in this table, SHALL set 
'xcmGenTrapClientRowStatus' (to 'createAndGo'),
'xcmGenTrapClientRowPersistence' (if not 'volatile'),
'xcmGenTrapClientSNMPVersion' (if not 'snmpV1Community'), and
'xcmGenTrapClientSNMPCommunity' (if not the current managed system
default in 'xcmGenBaseSNMPTrapCommunity')
SIMULTANEOUSLY (in the same SNMP Set-Request PDU).  

Conformance:  Conforming management agents SHALL NOT accept sets of 
'xcmGenTrapClientRowPersistence',
'xcmGenTrapClientSNMPVersion', or
'xcmGenTrapClientSNMPCommunity'
AFTER row creation (these objects are 'write-once').  

Usage:  OSI ASN.1 encoding rules (ISO 8825) and IETF SNMP rules REQUIRE 
that when strings are used as table indices (ie, as elements of instance
qualifiers for columnar objects), the first octet of each string MUST be
preceded by the count of octets in the string (see 'Mapping of the INDEX
clause' in SNMPv2-SMI, RFC 2578), unless the index is rightmost
(low-order) and specified with the IMPLIED keyword.  
Thus, the 'xcmGenTrapClientSNMPAddress' index of 'xcmGenTrapClientTable'
MUST be preceded by an octets count in SNMP request/response PDUs.  


XCMI Working Group                File 06gentc                 [Page 86]

XCMI General TC V5.601                                     04 April 2007


Usage:  OSI ASN.1 encoding rules (ISO 8825) and IETF SNMP rules REQUIRE 
that when object identifiers (OIDs) are used as table indices (ie, as
elements of instance qualifiers for columnar objects), the first arc
(sub-identifier) of each object identifier MUST be preceded by the count
of arcs (sub-identifiers) in the object identifier (see 'Mapping of the 
INDEX clause' in SNMPv2-SMI, RFC 2578), unless the index is rightmost
(low-order) and specified with the IMPLIED keyword.  
Thus, the 'xcmGenTrapViewObjectSubtree' index of 'xcmGenTrapViewTable'
MUST be preceded by an arcs count in SNMP request/response PDUs.  

Conformance:  The IMPLIED keyword SHALL NOT be used in XCMI MIB module
definitions (to avoid ambiguity of 'over-the-wire' encoding).  

In the XCMI General MIB, the 'trap registration' mechanism is supported 
by the following two simple objects in the Trap Client group:  

1)  'xcmGenTrapClientEntryCount' (count of currently 'active' rows);
2)  'xcmGenTrapClientSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, the 'trap registration' mechanism is supported 
by the following seven columnar objects in the Trap Client group:  

1)  'xcmGenTrapClientSNMPDomain' (client domain instance of this row);
2)  'xcmGenTrapClientSNMPAddress' (client address instance of this row);
3)  'xcmGenTrapClientRowStatus' (for acquire/release of this row);
4)  'xcmGenTrapClientIndex' (for allocation of subordinate trap views);
5)  'xcmGenTrapClientRowPersistence' (persistence of this row);
6)  'xcmGenTrapClientSNMPVersion' (SNMP version for generated traps);
7)  'xcmGenTrapClientSNMPCommunity' (community for generated traps).

In the XCMI General MIB, the 'trap registration' mechanism is supported 
by the following two simple objects in the Trap View group:  

1)  'xcmGenTrapViewEntryCount' (count of currently 'active' rows);
2)  'xcmGenTrapViewSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, the 'trap registration' mechanism is supported 
by the following four columnar objects in the Trap View group:  

1)  'xcmGenTrapViewObjectSubtree' (subtree 'in scope' for this row);
2)  'xcmGenTrapViewRowStatus' (for acquire/release of this row);
3)  'xcmGenTrapViewNotifySeverity' (severity filter for traps);
4)  'xcmGenTrapViewNotifyTraining' (training filter for traps).











XCMI Working Group                File 06gentc                 [Page 87]

XCMI General TC V5.601                                     04 April 2007



9.2.11.1.  Registration Algorithm for SNMP Trap Clients

To register for (some or all) SNMP traps emitted by a given host system,
SNMP trap clients (management stations or proxies) SHALL create one row 
in the Trap Client table, as follows:  

1)  Set 'xcmGenTrapClientSNMPDomain' (eg, to 'snmpUDPDomain'),
    'xcmGenTrapClientSNMPAddress' (eg, Internet UDP host/port address),
    'xcmGenTrapClientRowStatus' to 'createAndGo',
    'xcmGenTrapClientRowPersistence' (if not 'volatile'),
    'xcmGenTrapClientSNMPVersion' (if not 'snmpV1Community'), and
    'xcmGenTrapClientSNMPCommunity' (if not the current managed system
    default in 'xcmGenBaseSNMPTrapCommunity')
    SIMULTANEOUSLY (in the same SNMP Set-Request PDU);

2)  Check the returned Set-Response 'error-status' for 'noError';

3)  Get the agent-assigned value of 'xcmGenTrapClientIndex' (for use
    when creating subordinate rows in the 'xcmGenTrapViewTable').


9.2.11.2.  Registration Algorithm for SNMP Trap Views

To register for specific SNMP traps emitted by a given host system, SNMP
trap clients (management stations or proxies) SHALL create one or or
more rows in the Trap View table, as follows:  

1)  Using 'xcmGenTrapClientIndex' (from trap client registration above),
    Set 'xcmGenTrapViewObjectSubtree' (eg, to 'xcmJobV2StateAlert'), and
    'xcmGenTrapViewRowStatus' to 'createAndGo' and (optionally)
    'xcmGenTrapViewNotifySeverity' to an event severity level or
    'xcmGenTrapViewNotifyTraining' to an event training level
    (for filtering of generated events by severity or training required
    to repair the problem);

2)  Check the returned Set-Response 'error-status' for 'noError'.

















XCMI Working Group                File 06gentc                 [Page 88]

XCMI General TC V5.601                                     04 April 2007



9.2.11.3.  Registration for SNMPv1 Generic Traps

The SNMPv1 'generic' (or 'well-known') traps lack standard OIDs (due to 
their over-the-wire encoding).  See 'Convention for Defining Traps for
use with the SNMP' (RFC 1215, March 1991) for further information.  

Conformance:  All XCMI conforming management stations (clients) and
management agents (servers/devices) which support SNMPv1 traps SHALL use
the OIDs which are defined in 'SNMPv2 Agent MIB' (RFC 1907, January
1996) in section 2.4.1 'Well-Known Traps' to identify BOTH the SNMPv1
'generic' traps and their equivalent SNMPv2 'well-known' traps, for
purposes of SNMP trap registration in the Trap View table of the XCMI
General MIB.  These OIDs for 'generic' or 'well-known' traps are:  

--  See RFC 2578 (SNMPv2 SMI)
org                     OBJECT IDENTIFIER ::= { iso 3 }
dod                     OBJECT IDENTIFIER ::= { org 6 }
internet                OBJECT IDENTIFIER ::= { dod 1 }
snmpV2                  OBJECT IDENTIFIER ::= { internet 6 }


--  See RFC 1907 (SNMPv2 Agent MIB)
snmpMIB                 OBJECT IDENTIFIER ::= { snmpModules 1 }
snmpMIBObjects          OBJECT IDENTIFIER ::= { snmpMIB 1 }
snmpTraps               OBJECT IDENTIFIER ::= { snmpMIBObjects 5 }


--  See RFC 1215 (SNMPv1 Traps) and RFC 1907 (SNMPv2 Agent MIB)
coldStart               OBJECT IDENTIFIER ::= { snmpTraps 1 }
warmStart               OBJECT IDENTIFIER ::= { snmpTraps 2 }

--  See RFC 1215 (SNMPv1 Traps) and RFC 2233 (Interfaces Group MIB)
linkDown                OBJECT IDENTIFIER ::= { snmpTraps 3 }
linkUp                  OBJECT IDENTIFIER ::= { snmpTraps 4 }

--  See RFC 1215 (SNMPv1 Traps) and RFC 1907 (SNMPv2 Agent MIB)
authenticationFailure   OBJECT IDENTIFIER ::= { snmpTraps 5 }

--  See RFC 1215 (SNMPv1 Traps) and RFC 1213 (MIB-II)
--  OBSOLETE - do NOT use
egpNeighborLoss         OBJECT IDENTIFIER ::= { snmpTraps 6 }












XCMI Working Group                File 06gentc                 [Page 89]

XCMI General TC V5.601                                     04 April 2007



9.2.11.4.  Generation of SNMPv1 Traps

SNMPv1 trap definition and trap generation methods are documented in 'A 
Convention for Defining Traps for use with the SNMP' (RFC 1215).  The
generation of SNMPv1 traps (the 'over-the-wire' encoding) is singularly 
odd and therefore this section has been added to the XCMI General TC.  

The 'generic' SNMPv1 traps are defined with an ENTERPRISE clause of
'snmp' with a value of '{ mib-2 11 }'.  However, all 'generic' SNMPv1
Trap-PDUs are actually generated (the 'over-the-wire' encoding) with an 
'enterprise' field equal to the current value of 'sysObjectID' on the
generating managed system.  These 'generic' SNMPv1 traps are actually
discriminated (by receiving management stations) via the value of the
'generic-trap' field (such as 'warmStart(1)' when a managed system
reboots without a power-on cycle) and the value of the 'specific-trap'
field being set to '0' (unused).  

On the other hand, all 'enterprise-specific' SNMPv1 traps are defined
with an ENTERPRISE clause specifying the management enterprise under
whose registration authority the trap is defined (such as the alert in
the Printer MIB, RFC 1759, which uses 'printerV1Alert' as ENTERPRISE).  
All 'enterprise-specific' SNMPv1 Trap-PDUs are actually generated (the
'over-the-wire' encoding) with an 'enterprise' field equal to the value 
of the ENTERPRISE clause in their corresponding trap definition.  These 
'enterprise-specific' SNMPv1 traps are actually discriminated (by
receiving management stations) via the value of the 'generic-trap' field
being set to 'enterpriseSpecific(6)' (from RFC 1215) and the value of
the 'specific-trap' field being set to the value of the defining
TRAP-TYPE macro (such as the alert in the Printer MIB, RFC 1759, which
uses '1' as TRAP-TYPE value).  























XCMI Working Group                File 06gentc                 [Page 90]

XCMI General TC V5.601                                     04 April 2007



9.2.12.  Message Map (Cond Mand)

Support for client-side (SNMP manager) localization of server-side (SNMP
agent) message strings is provided in the Message Map group of the XCMI 
General MIB.  This support is independent of server dynamic and static
locales (language/country/charset) and SNMP version.  This support is
also comprehensive of ALL static (agent-generated) message strings,
including message strings in the numerous IETF and PWG legacy MIBs which
lack explicit localization support and/or use legacy string datatypes
such as 'DisplayString' (which may only contain US-ASCII, effectively
limiting string content to the English language).  


9.2.12.1.  Usage of xcmGenMessageMapStringIndexOID

Conformance:  All XCMI conforming management agents which implement the 
Message Map table:  

1)  SHALL create a row in the 'xcmGenMessageMapTable' for EACH instance 
    of EACH message string object in EACH implemented SNMP MIB
    (including those with XCMI explicit localization support); 
    
2)  SHALL set 'xcmGenMessageMapStringIndexOID' for ONE instance of ONE
    message string object in ONE implemented SNMP MIB to the message
    string object's fully qualified OID (including instance suffixes); 
    
3)  SHALL conform to the following requirements on the content of the
    accompanying 'xcmGenMessageMapStringLabel' object.  


Example:  

xcmGenMessageMapStringIndexOID  = prtInputMediaName.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)


9.2.12.2.  Usage of xcmGenMessageMapStringLabel

Conformance:  All XCMI conforming management agents which implement the 
Message Map table:  

1)  SHALL create a row in the 'xcmGenMessageMapTable' for EACH instance 
    of EACH message string object in EACH implemented SNMP MIB
    (including those with XCMI explicit localization support); 
    
2)  SHALL set 'xcmGenMessageMapStringLabel' for ONE instance of ONE
    message string object in ONE implemented SNMP MIB to the message
    string label (which has been properly registered in the [XMSG-REG]
    Xerox Message Label Registry) which corresponds to the current value
    of the message string object; 

XCMI Working Group                File 06gentc                 [Page 91]

XCMI General TC V5.601                                     04 April 2007

    
3)  SHALL conform to the following requirements on the content of the
    accompanying 'xcmGenMessageMapStringLabel' object.  


Example:  

xcmGenMessageMapStringLabel     = 'xs-iso-10175-mediaSize-iso-a4'
    -- 'xs' is a tag for Xerox standard message string labels
    -- 'iso-10175' is a tag for ISO 10175 (DPA) standard definitions
    -- 'mediaSize' is a tag for ISO 10175 (DPA) standard media sizes
    -- 'iso-a4' is a tag for ISO A4 (210 mm by 297 mm)


9.2.12.3.  Usage of XcmGenMessageStringLabel Type

Conformance:  All XCMI conforming management agents which implement the 
XcmGenMessageMapStringLabel textual convention (datatype):  

1)  SHALL register Xerox standard and experimental message string labels
    in the [XMSG-REG] Xerox Message Label Registry, according to the
    Xerox registration procedures (for current information, send email
    to the XCMI Editors); 
    
2)  SHALL ONLY use registered Xerox standard message string labels in
    released products; 
    
3)  SHALL NOT use registered experimental message string labels in
    released products (they exist solely to facilitate rapid product
    development cycles); 
    
4)  SHALL ONLY use registered Xerox standard message string labels which
    consist of display (NOT space) characters from the IANA registered
    charset 'utf-8' (ie, the UTF-8 octet-stream encoding of ISO 10646
    UCS-4, described in RFC 2279); 
    
5)  SHALL ONLY use registered Xerox standard message string labels which
    consist of no more than 64 UTF-8 display characters AND no more than
    128 total octets (in some scripts, less than 64 characters in UTF-8 
    octet-stream encoding); 
    
6)  SHALL ONLY use registered Xerox standard message string labels which
    conform to syntax specified in the 'XcmGenMessageMapStringLabel'
    textual convention in the XCMI General TC (06gentc) and any further 
    syntax restrictions which MAY be subsequently imposed by the current
    registration authority for the [XMSG-REG] Xerox Message Label
    Registry.  


9.2.12.4.  Example of Message Map Usage

To support reliable client-side localization of the many string objects 
defined in the IETF Printer MIB (RFC 1759) which LACK locale information
the 'xcmGenMessageMapTable' in the XCMI General MIB may be used.  An

XCMI Working Group                File 06gentc                 [Page 92]

XCMI General TC V5.601                                     04 April 2007

example for selected objects in the Input group (input trays) follows.  

Note:  The message string labels and corresponding message string object
values in the following example are for illustrative purposes ONLY and
MAY not be registered in the [XMSG-REG] Xerox Message Label Registry.  

xcmGenMessageMapStringIndexOID  = prtInputMediaDescription.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)
xcmGenMessageMapStringLabel     = 'xs-ietf-rfc1759-inputDescr-tray-1
    -- 'xs' is a tag for Xerox standard message string labels
    -- 'ietf-rfc1759' is a tag for IETF RFC 1759 standard definitions
    -- 'inputDescr' is a tag for IETF RFC 1759 input tray descriptions
    -- 'tray-1' is a tag for input tray 1
prtInputDescription.1.3         = 'input tray 3'
    -- Printer MIB (RFC 1759) - Input Group
    -- 'prtInputDescription' is of datatype 'OCTET STRING'
    -- (localized on server-side via 'prtGeneralCurrentLocalization')
    -- 'input tray 3' is a description for input tray 3

xcmGenMessageMapStringIndexOID  = prtInputMediaName.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)
xcmGenMessageMapStringLabel     = 'xs-iso-10175-mediaSize-iso-a4'
    -- 'xs' is a tag for Xerox standard message string labels
    -- 'iso-10175' is a tag for ISO 10175 (DPA) standard definitions
    -- 'mediaSize' is a tag for ISO 10175 (DPA) standard media sizes
    -- 'iso-a4' is a tag for ISO A4 (210 mm by 297 mm)
prtInputMediaName.1.3           = 'iso-a4'
    -- Printer MIB (RFC 1759) - Input Group
    -- 'prtInputMediaName' is of datatype 'OCTET STRING'
    -- (NOT localized on server-side, implicit English locale)
    -- 'iso-a4' is a media size in a fixed English locale (implicit)

xcmGenMessageMapStringIndexOID  = prtInputMediaType.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)
xcmGenMessageMapStringLabel     = 'xs-iso-10175-mediaType-envelope'
    -- 'xs' is a tag for Xerox standard message string labels
    -- 'iso-10175' is a tag for ISO 10175 (DPA) standard definitions
    -- 'mediaType' is a tag for ISO 10175 (DPA) standard media types
    -- 'envelope' is a tag for envelope media stock
prtInputMediaName.1.3           = 'envelope'
    -- Printer MIB (RFC 1759) - Input Group
    -- 'prtInputMediaType' is of datatype 'OCTET STRING'
    -- (NOT localized on server-side, implicit English locale)
    -- 'envelope' is a media type in a fixed English locale (implicit)

xcmGenMessageMapStringIndexOID  = prtInputMediaColor.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')

XCMI Working Group                File 06gentc                 [Page 93]

XCMI General TC V5.601                                     04 April 2007

    -- 'prtInputIndex' of '3' (third input tray)
xcmGenMessageMapStringLabel     = 'xs-iso-10175-mediaColor-yellow'
    -- 'xs' is a tag for Xerox standard message string labels
    -- 'iso-10175' is a tag for ISO 10175 (DPA) standard definitions
    -- 'mediaColor' is a tag for ISO 10175 (DPA) standard media colors
    -- 'yellow' is a tag for yellow media stock
prtInputMediaName.1.3           = 'yellow'
    -- Printer MIB (RFC 1759) - Input Group
    -- 'prtInputMediaColor' is of datatype 'OCTET STRING'
    -- (NOT localized on server-side, implicit English locale)
    -- 'yellow' is a media color in a fixed English locale (implicit)












































XCMI Working Group                File 06gentc                 [Page 94]

XCMI General TC V5.601                                     04 April 2007



9.2.13.  Message Text (Cond Mand)

Support for server-side (SNMP agent) localization of server-side (SNMP
agent) message strings is provided in the Message Text group of the XCMI
General MIB.  This support is independent of server dynamic and static
locales (language/country/charset) and SNMP version.  This support is
also comprehensive of ALL static (agent-generated) message strings,
including message strings in the numerous IETF and PWG legacy MIBs which
lack explicit localization support and/or use legacy string datatypes
such as 'DisplayString' (which may only contain US-ASCII, effectively
limiting string content to the English language).  


9.2.13.1.  Usage of xcmGenMessageTextStringIndexOID

Conformance:  All XCMI conforming management agents which implement the 
Message Text table:  

1)  SHALL create a row in the 'xcmGenMessageTextTable' for EACH instance
    of EACH message string object in EACH implemented SNMP MIB
    (including those with XCMI explicit localization support) in EACH of
    the supported locales on the managed host system; 
    
2)  SHALL set 'xcmGenMessageTextStringIndexOID' for ONE instance of ONE 
    message string object in ONE implemented SNMP MIB in ONE supported
    locale to the message string object's fully qualified OID (including
    instance suffixes); 
    
3)  SHALL set 'xcmGenMessageTextTargetLocale' for ONE instance of ONE
    message string object in ONE implemented SNMP MIB in ONE supported
    locale to the named locale of 'xcmGenMessageTextTargetString'.  


Example:  

xcmGenMessageTextStringIndexOID = prtInputMediaName.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)


9.2.13.2.  Example of Message Text Usage

To support reliable server-side localization of the many string objects 
defined in the IETF Printer MIB (RFC 1759) which LACK locale information
the 'xcmGenMessageTextTable' in the XCMI General MIB may be used.  An
example for selected objects in the Input group (input trays) follows.  

xcmGenMessageTextStringIndexOID = prtInputMediaDescription.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)

XCMI Working Group                File 06gentc                 [Page 95]

XCMI General TC V5.601                                     04 April 2007

xcmGenMessageTextTargetLocale   = 1
    -- target locale
    -- 'xcmGenLocalizationIndex' of '1' (for example English locale)
xcmGenMessageTextTargetString   = 'input tray 3'
    -- target string is of datatype 'XcmNamedLocaleUtf8String'
    -- (localized on server-side via 'xcmGenMessageTextTargetLocale')
    -- 'input tray 3' is an English description for input tray 3
prtInputDescription.1.3         = 'input tray 3'
    -- Printer MIB (RFC 1759) - Input Group
    -- 'prtInputDescription' is of datatype 'OCTET STRING'
    -- (localized on server-side via 'prtGeneralCurrentLocalization')
    -- 'input tray 3' is a description for input tray 3

xcmGenMessageTextStringIndexOID = prtInputMediaName.1.3
    -- Printer MIB (RFC 1759) - Input Group
    -- 'hrDeviceIndex' of '1' (typical for 'hrDevicePrinter')
    -- 'prtInputIndex' of '3' (third input tray)
xcmGenMessageTextTargetLocale   = 1
    -- target locale
    -- 'xcmGenLocalizationIndex' of '1' (for example English locale)
xcmGenMessageTextTargetString   = 'iso-a4'
    -- target string is of datatype 'XcmNamedLocaleUtf8String'
    -- (localized on server-side via 'xcmGenMessageTextTargetLocale')
    -- 'iso-a4' is a media size in the example English locale (explicit)
prtInputMediaName.1.3           = 'iso-a4'
    -- Printer MIB (RFC 1759) - Input Group
    -- 'prtInputMediaName' is of datatype 'OCTET STRING'
    -- (NOT localized on server-side, implicit English locale)
    -- 'iso-a4' is a media size in a fixed English locale (implicit)


























XCMI Working Group                File 06gentc                 [Page 96]

XCMI General TC V5.601                                     04 April 2007



9.2.14.  Notify Rule and Notify Detail (Cond Mandatory)

Protocol-independent and transport-independent notification client
(recipient) and notification detail (specific events, filters, etc.)
registration facilities are provided in the Notify Rule and Notify
Detail groups of the XCMI General MIB.

Note:  In the XCMI General MIB, the term 'notification rule' is
equivalent to the term 'Subscription object' in IPP Notifications.

Note:  The Notify Rule group is functionally equivalent to the Trap
Client and the Notify Detail
group is functionally equivalent to the Trap
View group, for non-SNMP delivery methods for event notifications.

Conformance:  Conforming management stations, when they first create
new rows in this table, SHALL set
'xcmGenNotifyRuleRowStatus' (to 'createAndGo'),
'xcmGenNotifyRuleRowPersistence' (to a persistence, if not 'volatile'),
'xcmGenNotifyRuleRecipientURI' (to a notification client URL),
'xcmGenNotifyRuleEventNames' (to a list of events),
'xcmGenNotifyRuleEventDelay' (to an event delay, if required),
'xcmGenNotifyRuleSeverityFilter' (to a set of event severity levels),
'xcmGenNotifyRuleTrainingFilter' (to a set of event training levels),
'xcmGenNotifyRuleCharset' (if not using the fixed locale), and
'xcmGenNotifyRuleNaturalLanguage' (if not using the fixed locale)
SIMULTANEOUSLY (in the same SNMP Set-Request PDU).  

Conformance:  Conforming management agents SHALL NOT accept sets of 
'xcmGenNotifyRuleRowPersistence'
AFTER row creation (this object is 'write-once').  

In the XCMI General MIB, 'event notification registration' is supported 
by the following two simple objects in the Notify Rule group:  

1)  'xcmGenNotifyRuleEntryCount' (count of currently 'active' rows);
2)  'xcmGenNotifyRuleSupportMaxCount' (max supported 'active' rows).

In the XCMI General MIB, 'event notification registration' is supported 
by the following eleven columnar objects in the Notify Rule group:  

1)  'xcmGenNotifyRuleIndex' (unique instance of notification rule);
2)  'xcmGenNotifyRuleRowStatus' (for acquire/release of this row);
3)  'xcmGenNotifyRuleRowPersistence' (persistence of this row);
4)  'xcmGenNotifyRuleRecipientURI' (client URL for event delivery);
5)  'xcmGenNotifyRuleEventNames' (list of events);
6)  'xcmGenNotifyRuleEventDelay' (optional delay for event delivery);
7)  'xcmGenNotifyRuleSeverityFilter' (set of severity levels);
8)  'xcmGenNotifyRuleTrainingFilter' (set of training levels);
9)  'xcmGenNotifyRuleCharset' (if not using the fixed locale);
10) 'xcmGenNotifyRuleNaturalLanguage' (if not using the fixed locale);
11) 'xcmGenNotifyRuleSequenceNumber' (sequence number for events sent).

XCMI Working Group                File 06gentc                 [Page 97]

XCMI General TC V5.601                                     04 April 2007


In the XCMI General MIB, 'event notification registration' is supported 
by the following two simple objects in the Notify Detail group:  

1)  'xcmGenNotifyDetailEntryCount' (count of currently 'active' rows);
2)  'xcmGenNotifyDetailSupportMax' (max supported 'active' rows).

In the XCMI General MIB, 'event notification registration' is supported 
by the following four columnar objects in the Notify Detail group:  

1)  'xcmGenNotifyDetailType' (type of notification detail);
2)  'xcmGenNotifyDetailIndex' (unique instance of notification detail);
3)  'xcmGenNotifyDetailRowStatus' (for acquire/release of this row);
4)  'xcmGenNotifyDetailString' (string value of notification detail).









































XCMI Working Group                File 06gentc                 [Page 98]

XCMI General TC V5.601                                     04 April 2007



9.2.14.1.  Registration Algorithm for Notify Clients

To register for (some or all) events emitted by a given host system,
event clients (management stations or proxies) SHALL create one row in
the Notify Rule table, as follows:  

1)  Set 'xcmGenNotifyRuleRowStatus' to 'createAndGo',
    'xcmGenNotifyRuleRowPersistence' (if not 'volatile'),
    'xcmGenNotifyRuleRecipientURI' (client URL for event delivery),
    'xcmGenNotifyRuleEventNames' (list of events),
    'xcmGenNotifyRuleEventDelay' (optional delay for event delivery),
    'xcmGenNotifyRuleSeverityFilter' (set of severity levels),
    'xcmGenNotifyRuleTrainingFilter' (set of training levels),
    'xcmGenNotifyRuleCharset' (if not using the fixed locale),
    'xcmGenNotifyRuleNaturalLanguage' (if not using the fixed locale),
    SIMULTANEOUSLY (in the same SNMP Set-Request PDU);

2)  Check the returned Set-Response 'error-status' for 'noError'.


9.2.14.2.  Registration Algorithm for Notify Details

To register for specific events emitted by a given host system (or other
notification details, such as additional event recipient URLs), event
clients (management stations or proxies) SHALL create one or or more
rows in the Notify Detail table, as follows:  

1)  Using 'xcmGenNotifyRuleIndex' (from notify rule registration above),
    Set 'xcmGenNotifyDetailRowStatus' to 'createAndGo' and
    'xcmGenNotifyDetailString' to the string value of the notification
    detail specified in the 'xcmGenNotifyDetailType' instance qualifier;

2)  Check the returned Set-Response 'error-status' for 'noError'.


9.2.14.3.  Example of Email Notification

Example of tables in XCMI General MIB for email notification:  


--  alert notification groups (notification rules)
--  for 'xcmGenNotifyIndex' from '1' to '3'
xcmGenNotifyRuleRowStatus.1             = 'active'
xcmGenNotifyRuleRowPersistence.1        = 'nonVolatile'
xcmGenNotifyRuleRecipientURI.1          = ''   -- see notify details
xcmGenNotifyRuleEventNames.1            = ''   -- see notify details
xcmGenNotifyRuleEventDelay.1            = ''   -- see notify details
xcmGenNotifyRuleSeverityFilter.1        = '15' -- report, warning, error
xcmGenNotifyRuleTrainingFilter.1        = '60' -- none, trained, etc.
xcmGenNotifyRuleCharset.1               = 'utf-8(106)' -- UTF-8 charset
xcmGenNotifyRuleNaturalLanguage.1       = 'de' -- German language
xcmGenNotifyRuleSequenceNumber.1        = '0' -- initial sequence number

XCMI Working Group                File 06gentc                 [Page 99]

XCMI General TC V5.601                                     04 April 2007


--  alert client address
--  for 'xcmGenNotifyDetailIndex' from '1' to '5'
xcmGenNotifyDetailString.1.notifyRecipientURI(10).1
    = 'mailto:joe@sample.com'

--  alert type name
--  for 'xcmGenNotifyDetailIndex' from '1' to 'n'
xcmGenNotifyDetailString.1.notifyEventNames(20).1
    = 'jammed' -- from 'hrPrinterDetectedErrorState' in RFC 2790
xcmGenNotifyDetailString.1.notifyEventNames(20).2
    = 'lowPaper' -- from 'hrPrinterDetectedErrorState' in RFC 2790

--  'jam delay timer'
--  for 'xcmGenNotifyDetailIndex' from '1' to 'n'
xcmGenNotifyDetailString.1.notifyEventDelay(21).1
    = '300' -- 5 minutes delay for 'jammed' event delivery

--  'Reply-To' attribute
--  for 'xcmGenNotifyDetailIndex' from '1' to 'n'
xcmGenNotifyDetailString.1.notifyMessageHeaderText(31).1
    = 'Reply-To: J_Smith@sample.com' -- see RFC 2822/822

--  event message content by keyword
--  for 'xcmGenNotifyDetailIndex' from '1' to 'n'
xcmGenNotifyDetailString.1.notifyMessageContentKeys(32).1
    = 'sysName,sysLocation,prtGeneralSerialNumber' -- see RFC 1213, PMv2

--  event message content free-text
--  for 'xcmGenNotifyDetailIndex' from '1' to 'n'
xcmGenNotifyDetailString.1.notifyMessageContentText(33).1
    = 'Please call help desk'


9.2.14.4.  Mapping IPP Subscription to XCMI General MIB

Below is the complete mapping from the Subscription object specified in 
IPP Notifications to the XCMI General MIB.  As of June 2001, the latest 
draft of the IPP Event Notification Specification is at:  

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-06.txt 


IPP Subscription object attributes      XCMI General MIB objects/details
----------------------------------      --------------------------------
--  Subscription Template Attributes
5.3.1 notify-recipient-uri              xcmGenNotifyRuleRecipientURI
                                        - notifyRecipientURI (detail)

5.3.2 notify-events                     xcmGenNotifyRuleEventNames
                                        - notifyEventNames (detail)

5.3.3 notify-attributes                 xcmGenNotifyRuleDetailString
                                        - notifyContentKeys (detail)

XCMI Working Group                File 06gentc                [Page 100]

XCMI General TC V5.601                                     04 April 2007


5.3.4 notify-user-data                  xcmGenNotifyRuleDetailString
                                        - notifyContentText (detail)

5.3.5 notify-charset                    xcmGenNotifyRuleCharset

5.3.6 notify-natural-language           xcmGenNotifyRuleNaturalLanguage

5.3.7 notify-lease-duration             [xcmGenNotifyRuleRowPersistence]

5.3.8 notify-time-interval              xcmGenNotifyRuleEventDelay

--  Subscription Description Attributes
5.4.1 notify-subscription-id            xcmGenNotifyRuleIndex

5.4.2 notify-sequence-number            xcmGenNotifyRuleSequenceNumber

5.4.3 notify-lease-expiration-time      [xcmGenNotifyRuleRowPersistence]

5.4.4 notify-printer-up-time            [sysUptime in RFC 1213]

5.4.5 notify-printer-uri                [xcmCOInternetIPPHostAddress]

5.4.6 notify-job-id                     [jmJobIndex in RFC 2707]

5.4.7 notify-subscriber-user-name       [no mapping]





























XCMI Working Group                File 06gentc                [Page 101]

XCMI General TC V5.601                                     04 April 2007

Change Log 
--
--












XCMI Working Group                File 06gentc                [Page 111]

XCMI General TC V5.601                                     04 April 2007
                           TABLE OF CONTENTS                            

1.  Introduction ...............................................       2
2.  SNMP Network Management Framework ..........................       3
  2.1.  SNMPv1 Network Management Framework ....................       3
    2.1.1.  Object Definitions .................................       3
  2.2.  SNMPv2 Network Management Framework ....................       4
  2.3.  SNMPv3 Network Management Framework ....................       5
3.  Managed Object Usage .......................................       6
  3.1.  Overview of Groups in the General MIB ..................       6
  3.2.  Relationship to other MIBs .............................      13
    3.2.1.  IETF MIB-II (RFC 1213) .............................      13
    3.2.2.  IETF Host Resources MIB (RFC 2790) .................      13
    3.2.3.  IETF Printer MIB (RFC 1759) ........................      13
    3.2.4.  XCMI Standard MIBs .................................      14
  3.3.  Overview of Groups in IETF MIB-II ......................      15
4.  Managed Object Definitions .................................      19
  4.1.  Definition of General Textual Conventions ..............      19
    4.1.1.  Cardinal16 .........................................      20
    4.1.2.  Cardinal32 .........................................      20
    4.1.3.  Cardinal64High .....................................      20
    4.1.4.  Cardinal64Low ......................................      20
    4.1.5.  CodedCountry .......................................      20
    4.1.6.  CodedLanguage ......................................      20
    4.1.7.  CodeIndexedStringIndex .............................      21
    4.1.8.  Counter64High ......................................      21
    4.1.9.  Counter64Low .......................................      21
    4.1.10.  Gauge64High .......................................      21
    4.1.11.  Gauge64Low ........................................      22
    4.1.12.  Integer64High .....................................      22
    4.1.13.  Integer64Low ......................................      22
    4.1.14.  Ordinal16 .........................................      22
    4.1.15.  Ordinal32 .........................................      22
    4.1.16.  Ordinal64High .....................................      22
    4.1.17.  Ordinal64Low ......................................      22
    4.1.18.  XcmFixedLocaleDisplayString .......................      23
    4.1.19.  XcmFixedLocaleUtf8String ..........................      23
    4.1.20.  XcmNamedLocaleUtf8String ..........................      24
    4.1.21.  XcmGenGroupSupport ................................      24
    4.1.22.  XcmGenLogFullPolicy ...............................      25
    4.1.23.  XcmGenMessageMapStringLabel .......................      25
    4.1.24.  XcmGenNotifySchemeSupport .........................      29
    4.1.25.  XcmGenNotifySeverityFilter ........................      30
    4.1.26.  XcmGenNotifyTrainingFilter ........................      31
    4.1.27.  XcmGenOptionValueSyntax ...........................      31
    4.1.28.  XcmGenReconfOptionState ...........................      33
    4.1.29.  XcmGenRowPersistence ..............................      34
    4.1.30.  XcmGenSNMPDomain ..................................      35
    4.1.31.  XcmGenSNMPVersion .................................      36
    4.1.32.  XcmGenSNMPv2ErrorStatus ...........................      36
    4.1.33.  XcmGlobalUniqueID .................................      37
    4.1.34.  Dummy Group (to suppress compiler warnings) .......      40
5.  Acknowledgements ...........................................      46
6.  References .................................................      47
  6.1.  General References .....................................      47

XCMI Working Group                 File 06gentc                 [Page i]

XCMI General TC V5.601                                     04 April 2007
                           TABLE OF CONTENTS                            

  6.2.  IETF SNMPv2 Standards References .......................      48
  6.3.  IETF SNMPv3 Standards References .......................      49
7.  Security Considerations ....................................      50
8.  Authors' Addresses .........................................      50
9.  Supplement .................................................      51
  9.1.  XCMI Supplement to IETF MIB-II .........................      51
    9.1.1.  IETF MIB-II System (Mandatory) .....................      51
      9.1.1.1.  Usage of sysDescr and sysObjectID ..............      53
    9.1.2.  IETF MIB-II Interfaces (Mandatory) .................      54
      9.1.2.1.  Usage of ifDescr and ifSpecific ................      57
    9.1.3.  IETF MIB-II Address Translation (Deprecated) .......      58
    9.1.4.  IETF MIB-II IP (Cond Mandatory) ....................      58
    9.1.5.  IETF MIB-II ICMP (Cond Mandatory) ..................      58
    9.1.6.  IETF MIB-II TCP (Cond Mandatory) ...................      58
      9.1.6.1.  Usage of tcpConnTable ..........................      59
    9.1.7.  IETF MIB-II UDP (Cond Mandatory) ...................      59
      9.1.7.1.  Usage of udpTable ..............................      59
    9.1.8.  IETF MIB-II EGP (Deprecated) .......................      59
    9.1.9.  IETF MIB-II Transmission (Mandatory) ...............      59
    9.1.10.  IETF MIB-II SNMP (Mandatory) ......................      60
  9.2.  XCMI Supplement to XCMI General MIB ....................      61
    9.2.1.  PresentOnOff Persistency ...........................      61
    9.2.2.  Text Strings and Localization ......................      61
    9.2.3.  General Base (Mandatory) ...........................      63
    9.2.4.  General Localization (Cond Mand) ...................      65
    9.2.5.  Current Localization (Cond Mand) ...................      65
    9.2.6.  Fixed Localization (Cond Mand) .....................      66
      9.2.6.1.  Rationale for Fixed Locale Strings .............      67
      9.2.6.2.  Management Station/Agent Conformance ...........      67
    9.2.7.  Code Indexed String (Cond Mand) ....................      68
      9.2.7.1.  Charset Conversions using CodeIndexedString ....      69
    9.2.8.  General Lock (Cond Mand) ...........................      71
      9.2.8.1.  Use of Advisory Locks in XCMI ..................      71
      9.2.8.2.  Acquiring an Advisory Lock (Dynamic Rows) ......      73
      9.2.8.3.  Acquiring an Advisory Lock (Static Rows) .......      74
      9.2.8.4.  Releasing an Advisory Lock (Dynamic Rows) ......      75
      9.2.8.5.  Releasing an Advisory Lock (Static Rows) .......      75
      9.2.8.6.  Acquiring ENTIRE System Lock ...................      76
      9.2.8.7.  Management Agent Conformance ...................      77
      9.2.8.8.  Management Station Conformance .................      77
    9.2.9.  General Reconf and General Option (Cond Mand) ......      78
      9.2.9.1.  Use of Reconfiguration Sets in XCMI ............      79
      9.2.9.2.  Validation Algorithm for Reconfiguration .......      80
      9.2.9.3.  Activation Behavior for Reconfiguration ........      81
    9.2.10.  Client Data (Cond Mand) ...........................      82
      9.2.10.1.  Rationale for Client Data Areas ...............      82
      9.2.10.2.  Acquiring a Client Data Area ..................      83
      9.2.10.3.  Releasing a Client Data Area ..................      84
      9.2.10.4.  Management Agent Conformance ..................      84
      9.2.10.5.  Management Station Conformance ................      85
    9.2.11.  Trap Client and Trap View (Mandatory) .............      86
      9.2.11.1.  Registration Algorithm for SNMP Trap Clients ..      88
      9.2.11.2.  Registration Algorithm for SNMP Trap Views ....      88

XCMI Working Group                File 06gentc                 [Page ii]

XCMI General TC V5.601                                     04 April 2007
                           TABLE OF CONTENTS                            

      9.2.11.3.  Registration for SNMPv1 Generic Traps .........      89
      9.2.11.4.  Generation of SNMPv1 Traps ....................      90
    9.2.12.  Message Map (Cond Mand) ...........................      91
      9.2.12.1.  Usage of xcmGenMessageMapStringIndexOID .......      91
      9.2.12.2.  Usage of xcmGenMessageMapStringLabel ..........      91
      9.2.12.3.  Usage of XcmGenMessageStringLabel Type ........      92
      9.2.12.4.  Example of Message Map Usage ..................      92
    9.2.13.  Message Text (Cond Mand) ..........................      95
      9.2.13.1.  Usage of xcmGenMessageTextStringIndexOID ......      95
      9.2.13.2.  Example of Message Text Usage .................      95
    9.2.14.  Notify Rule and Notify Detail (Cond Mandatory) ....      97
      9.2.14.1.  Registration Algorithm for Notify Clients .....      99
      9.2.14.2.  Registration Algorithm for Notify Details .....      99
      9.2.14.3.  Example of Email Notification .................      99
      9.2.14.4.  Mapping IPP Subscription to XCMI General MIB ..     100







































XCMI Working Group                File 06gentc                [Page iii]
